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FOREWORD 

This Indian Standard was adopted by the Bureau of Indian Standards, after the draft finalized by the Nuclear 
Instrumentation Sectional Committee had been approved by the Electronics and Telecommunication Division 
Council. 

Computer systems are extensively used for on line monitoring of the reactor core against blockage of coolant 
flow, on line power regulation, fuel handling operation, supervision of process parameters against safety 
thresholds, event sequence analysis, measurement of radiation level, etc. The basic principles for the design of 
nuclear instrumentation as specifically applied to the safety systems of nuclear and radiation facilities have been 
interpreted in existing standards with reference to hardwired systems as the 'Safety Guide 50-SG-D2' of the 
I.A.E.A. 

This standard has been developed to interpret these principles for the utilization of digital systems — 
multi -processor distributed systems as well as larger scale central processor systems — in the safety systems 
of nuclear facilities. The other process plants may find use of this standard in the design and use of their computer 
based systems. It discusses the software system principles and requirements and should be read in conjunction 
with IS 15399 : 2003 'Hardware for computers in the safety system of nuclear and radiation facilities.' 

This standard may also be useful as a guide for other computer systems requiring real time applications. 

Aspects for which special recommendations have been produced, due to the unique nature of computer systems 
and their software are: 

a) Established hardware criteria as far as they affect the software, taking careful account of the high degree 
of interdependency between hardware and software; 

b) A general approach to software development to assure the production of the highly reliable software 
required; 

c) A general approach to software verification and computer system validation; and 

d) Procedures for software maintenance, modification and configuration control. 

While preparing this standard, assistance has been derived from IEC 60880 (1986) 'Software for computers in 
the safety systems of nuclear power stations' issued by the International Electrotechnical Commission. 

The composition of the Committee responsible for formulation of this standard is given in Annex G. 
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Indian Standard 



SOFTWARE FOR COMPUTERS IN THE SAFETY 
SYSTEMS OF NUCLEAR AND RADIATION 

FACILITIES 



1 SCOPE 

1.1 This standard is applicable to highly reliable 
software required for computers to be used in the 
safety systems of nuclear facilities for safety functions 
— Class 1 functions according to IS 12772 : 2003 
'Application of computers to nuclear reactor 
instrumentation and control (first revision)". This 
includes the safety actuation systems, the safety 
system support features and the protection systems. 

1.2 This standard covers requirements for each stage 
of software generation, including design, 
development, qualification and operation as well as 
the documentation for each stage of the software 
generation for the purpose of achieving highly reliable 
software. An acceptable approach to the development 
and content of the software requirements is given in 
Annex A. 

The principles applied in developing these 
requirements include: 

a) Best available practice; 

b) Top-down design methods; 

c) Modularity; 

d) Verification of each phase; 

e) Clear documentation; 

f) Auditable documents; and 

g) Validation testing. 

1.3 Additional guidance and information on how to 
comply with the requirements of the main part of this 
standard is given in Annex B to Annex F. 

1.4 If practices differing from those of the Annexes 
are used, they shall be documented and auditable 
according to the requirements of the main part of this 
standard. 

2 REFERENCES 

The following standards are necessary adjuncts to this 
standard: 

IS No. Title 

IS 12772 : 2003 Application of computers to nuclear 
reactor instrumentation and control 
(first revision) 

IS 15399 : 2003 Hardware for computers in the 
safety system of nuclear and 
radiation facilities 



3 TERMS AND DEFINITIONS 

For the purpose of this standard, following definitions 
shall apply. 

3.1 Application Programme — A computer 
programme that performs a task related to the process 
being controlled rather than the functioning of the 
computer itself. 

3.2 Code Compaction — The purposeful reduction 
in memory size required for a computer programme 
by the elimination of redundant or extraneous 
instructions. 

3.3 Computer — A programmable functional unit 
that consists of one or more associated processing 
units and peripheral equipment, that is controlled by 
internally stored programmes and that can perform 
substantial computation, including numerous 
arithmetic operations or logic operations, without 
human intervention during a run. 

NOTE — A computer may be a stand-alone unit or may consist 
of several interconnected units. 

3.4 Computer Programme — A set of ordered 
instructions and data that specify operations in a form 
suitable for execution by a digital computer. 

3.5 Computer System — A system consisting of one 
or more computers (comprising hardware as well as 
software) collectively forming a functional unit of an 
instrumentation and control system. 

3.6 Data — A representation of facts, concepts or 
instructions in a formalized manner suitable for 
communication, interpretation or processing by a 
computer. 

3.7 Defence in Depth — Provision of multiple levels 
of protection for ensuring safety of workers, the public 
or the environment. 

3.8 Diversity — Existence of different means of 
performing a required function (for example, other 
physical principles, other ways of solving the same 
task). 

3.9 Fault Tolerance — The built-in capability of a 
system to provide continued correct execution in the 
presence of a limited number of hardware or software 
faults. 
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3.10 Graceful Degradation — Stepwise reduction 
of system functions in response to detected failures 
while essential functions are maintained. 

3.11 Initialize — To set counters, switches, 
addresses, or contents of storage devices to zero or 
other starting values at the beginning of, or at 
prescribed points in, the operation of a computer 
programme. 

3.12 Integration Tests — Tests performed during 
the hardware/software integration process prior to 
computer system validation to verify compatibility of 
the software and the computer system hardware. 

3.13 Procedure — A portion of a computer 
programme which is named and which perform a 
specific task. 

3.14 Redundancy — Provision of alternative 
(identical or diverse) elements or systems so that any 
one can perform the required function regardless of the 
state of operation or failure of any other. 

3.15 Single Failure — A random failure, which 
results in the loss of capability of a component to 
perform its intended safety function. Consequential 
failures resulting from a single random occurrence are 
considered to be part of the single failure. 

3.15,1 Single Failure Criterion — A criterion applied 
to a system such that it is capable of performing its 
safety task in the presence of any single failure. 

3.16 Software — Programmes, procedures, rules and 
any associated documentation pertaining to the 
operation of a computer system. 

3.17 Software Life Cycle — The period of time that 
starts when a software product is conceived and ends 
when the product is no longer available for use. The 
software life cycle typically includes a requirements 
phase, design phase, implementation phase, test phase, 
installation and check-out phase, operation and 
maintenance phase. 

3.18 Software Modification — Changes of already 
agreed documents leading to a change to the 
executable code or its data. 

3.19 Software Modularity — The software attribute 
that provides a structure of highly independent 
computer programme units that are discrete and 
identifiable with respect to translating, testing and 
combining with other units. 

3.20 Validation — The test and evaluation of the 
integrated computer system (hardware and software) 
to ensure compliance with the functional, performance 
and interface requirements. 

3.21 Verification — The process of determining 
whether or not the product of each phase of the digital 



computer system development process fulfils all the 
requirements imposed by the previous phase. 

3.22 Availability — The ability of an item to be in a 
state to perform a required function under given 
conditions at a given instant of time or over a given 
time interval, assuming that the required external 
resources are provided. 

3.23 Component 

a) Hardware — Items from which the system is 
assembled (for example, integrated circuits, 
resistors, capacitors, wires, connectors, tran- 
sistors, switches, etc). 

b) Software — A basic part of a programme. 

3.24 Design — The theoretical work which leads 
towards a system requirements specification. 

3.25 Development — The experimental, test 
demonstration work which is intended to prove the 
success of any parts of the design whose performance 
cannot be ensured by theoretical work alone. 

3.26 Maintainability — The probability that a given 
active maintenance action to an item under given 
conditions of use can be carried out within a stated 
time interval when the maintenance is performed 
under stated conditions and using stated procedures 
and resources. 

3.27 Maintenance — The combination of all 
technical and administrative actions, including 
supervision actions, intended to retain an item in, or 
restore it to, a state in which it can perform a required 
function. 

3.28 Module — Any assembly of interconnected 
components which constitutes an identifiable device, 
instrument or piece of equipment. A module can be 
removed as a unit and replaced with a spare. It has 
definable performance characteristics which permit it 
to be tested as a unit. A module could be a card, a draw 
out circuit breaker or any other sub-assembly of a 
larger device, provided it meets the requirements of 
this definition. 

3.29 Qualified Life — The period of time for which 
satisfactory performance can be verified for a 
specified set of operating conditions. 

330 Reliability — The probability that a failure 
which causes deviation from the required output by 
more than specified tolerances, in a specific 
environment, does not occur during a specified 
exposure period. 

3 31 Sub-System — A division of a system that in 
itself has the characteristics of a system. 

3.32 System — A set of interconnected elements 
constituted to achieve a given objective by performing 
a specified function. 
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4 PROJECT STRUCTURE 

Any project will normally be divided up into a number 
of phases. Each phase is to some extent self-contained 
but will depend on other phases and will, in its turn, be 
depended on by others. These phases are informally 
recognizable by the specific activities pertinent to 
them. 

For safety related applications, these phases shall be 
formalized and none of the identified phases shall be 
omitted. 

4.1 General 

The following general factors determine the activities 
in implementation of a project. 

4.1.1 The whole software life cycle shall be 
considered. 

4.1.2 Each phase of the software life cycle shall be 
divided into elementary tasks with a well-defined 
activity for each of them. 

4.1.3 Every product shall be systematically checked 
after each phase (see B-5.7). 

4.1.4 The tasks of quality assurance should be run 
generally in parallel with the other tasks of the life 
cycle. 

4.1.5 Each phase shall include generation of the 
appropriate documents (see F-3). 

4.1.6 Each phase shall be systematically terminated 
by a critical review. Critical reviews form a major part 
of the verification process of the software project 
(see 6). 

4.1.7 Every verification step or critical review shall 
result in a report on the analysis performed, the 
conclusions reached and the resolutions agreed. This 
report shall be included in the documentation. 

4.1.8 A list of documents required as a minimum 
through the software life cycle is given in Annex F. 

4.2 Software Quality Assurance Plan 

A quality assurance plan shall exist or be established 
at an early stage either as a part of the computer system 
specification (see 4) or as a companion document. 

Although the whole of this standard and its annexes 
can be considered as a quality assurance plan for safety 
related software, special quality assurance plans may 
be adopted for individual product phases or particular 
software components according to organizational 
standards. 

These plans should address all quality assurance 
procedures required during all phases of the software 
life cycle. 



5 SOFTWARE REQUIREMENTS 

5.1 General 

5.1.1 The software requirements (see M2 ofF-1 
and F-3) shall be derived from requirements of the 
safety systems and are part of the computer system 
specification. The computer system specification is a 
description of the combined hardware/software 
system and states the objectives and functions 
assigned to the computer system. The safety critical 
and safety related functions shall be clearly identified 
in the requirement specification document. 

5.1.2 The software requirements describe the 
product, not the project. They shall describe what has 
to be done and not how it has to be done. An 
acceptable approach to the development and content 
of the software requirements, which is consistent with 
this clause, is given in Annex A. 

5.13 Whereas the main purpose of the software 
requirements document is to form the basis for 
software development, the licensing aspects should 
not be neglected. Therefore, it may contain aspects of 
minor importance to software design which are, 
however, a background for licensing. Such aspects 
maybe: 

a) Risk considerations; 

b) Recommendations for functions or engineered 
safety features; and 

c) Other items that provide the background for 
specific requirements. 

5.1.4 The software functional requirements represent 
an expansion of the functions which are assigned to 
the computer system and which are to be implemented 
by the computer system. 

5.1.5 The software reliability requirements represent 
an expansion of the reliability requirements of the 
computer system. They shall be derived in a similar 
way to the functional requirements. 

5.2 The computer system specification shall give an 
external and synthetic view of the functions to be 
implemented by the software of the computer system 
(see A-2.1). 

5.3 The computer system configuration shall be 
described using as a background of the reliability 
requirements and the environment of the system, since 
reliability properties and system configuration are 
closely connected (see A-2.2). 

5.4 For interaction between the computer system and 
plant operator or any other person 10.1.2 and A-2.3 are 
applicable. 

5.5 The interface between the computer system and 
any other system either within or outside the nuclear 
plant, wherever a direct connection exists or is 
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planned, shall be identified and documented indicating 
the specific interfaces and the related software 
requirements {see A-2.4), 

5.6 The constraints between hardware and software 
shall be described {see A-2.6). A reference to the 
hardware requirements document shall be made. 

5.7 The computer system software shall continuously 
supervise both itself and the hardware {see A-2.8). 
This is considered a primary factor in the achievement 
of the overall system reliability requirements. 

5.7.1 Self-supervision shall meet the following 
requirements, unless it is proved that other means 
provide the same degree of safety: 

a) No single failure shall be able to block directly 
or indirectly any safety related function of the 
system. 

b) Those parts of the memory that contain code 
or invariable data shall be monitored to ensure 
integrity of the memory. 

5.7.2 The safety system software shall be designed in 
such a manner that essential functions of the whole 
safety system be testable during the operation of the 
facility. 

5.7.3 If any failure is detected during plant operation, 
appropriate and timely automatic actions shall be 
taken. This may require giving due consideration to 
avoiding spurious trips. 

5.7.4 System self -checking shall not adversely affect 
the intended system functions. 

5.7.5 The safety system software shall be designed so 
as to meet the requirements of periodic testing which 
takes place within specified maximum intervals (for 
example, shut-down periods). 

a) Every single function shall be coverable by 
periodic testing. 

b) Any degradation of the execution of safety 
functions shall be detected. 

c) The basic self-checking functions shall also be 
testable during periodic tests. 

The software should be able to collect automatically 
all information gained during periodic testing. Further 
details for periodic testing are given in 10.3. 

5.8 Software functional requirements shall be 
^presented according to a standard whose formality 
should not preclude readability {see A-2.9). The 
requirements shall be unequivocal, testable or 
verifiable and realizable. 

5.9 The use of a formal specification language may 
be a help to show coherence and completeness of the 
software functional requirements. Automatic tools 
may be used for this purpose. 



5.10 The software functional requirements shall be 
provided: 

a) To the authors of the computer system require- 
ments documents for assessment and approval 
prior to programming; 

b) To the software design team manager for 
approval and with respect to feasibility and 
readability; and 

c) To the licensers with respect to compliance 
with the overall plant safety requirements for 
licensing approval. 

6 DEVELOPMENT (DESIGN AND CODING) 
OF SAFETY SYSTEM SOFTWARE 

The following recommendations provide a guide to 
good practice for writing software which is as 
error-free as possible from the very beginning and 
which can easily be verified. 

The software functional requirements specification 
should be available before the design and coding phase 
of programme development begins. 

6.1 Principles of Development (Design and 
Coding) 

6.1.1 The following general principles for 
development are based on experience in producing 
error-free and understandable software. 

6.1.1.1 The software design shall include 
self-supervision of control flow and data. On failure 
detection, appropriate action shall be taken. 

6.1.1.2 The programme structure should be based on 
a decomposition into modules. 

6.1.13 The programme structure should be simple 
and easy to understand, both in its overall design and 
in its details. Tricks, recursive structures and 
unnecessary code compaction should be avoided. 

6.1.1.4 The final source programme should be 
readable from start to end. 

6.1.1.5 Good documentation shall be provided. 

6.1.2 From these principles the following 
recommendations are derived: 

a) Measures to obtain the required reliability in- 
cluding self-supervision should be chosen at 
the outset of the development {see B-4); 

b) A top down approach to software development 
should be preferred to a bottom up approach 
{see B-2); 

c) A conceptual model of system structure should 
be adopted at the beginning of each software 
project {see B-3); 

d) The programme should be written to allow 
easy testing {see B-5 and B-6); and 
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e) Where standard software from a manufacturer 
or supplier is used, it should be shown to have 
operated satisfactorily (see B-3.3). For safety 
critical application, the listing of the software 
shall be available for verification by the licens- 
ing agency. 

6.2 Language, Translator and Other Tools 

Guidance for selection of language, translator, etc, are 
given in Annex D. 

Even though a specific programming language cannot 
be required, the following may be considered as 
common basic rules for safety system programming 
languages. 

6.2.1 Languages with a thoroughly tested translator 
should be used. If no thoroughly tested translator is 
employed, additional verification shall show that the 
result of the translation is correct. 

6.2.2 The language should be completely and 
unambiguously defined, otherwise the use of the 
language shall be restricted to completely and 
unambiguously defined features. This applies in a 
similar way if there is any doubt about the correct 



translation of a specific language feature or a particular 
combination of such features. 

6.2.3 Problem oriented languages are strongly 
preferred to machine oriented ones. 

6.2.4 As well as the specific points mentioned in 
Annex D, a programming language for safety systems 
and its translator should not prevent by their design: 

a) Error-limiting constructs; 

b) Translation-time type checking; and 

c) Run-time type and array bound check, and 
parameter checking. 

6.2.5 Automatic testing aids should be available. 

6.2.6 The use of automatic tools is recommended. 
6.3 Detailed Recommendations 

6.3.1 Development 

In Annex B a set of recommendations is given which 
specifies in detail the aspects identified in 6.2. 

The headings of the individual recommendations of 
Annex B as well as relevant clauses of this standard 
can also be attributed to the two major parts of 
programme development, design and coding, according 
to Table 1. 



Table 1 Procedural and Structural Aspects of Design and Coding of User Programme for Safety System 

(Clause 6.3.1) 



SI Parameter 
No. 

(1) C) 


Procedural Aspects 


Item 


Clause 


Structural Aspects 


Item 


Clause 


(3) 


(4) 


(5) 


(6) 


(7) 


(8) 


i) Design 


Changeability 
Top-down approach 


B-2.1 

B-2.2 


4 


Control and access structures 


B-3.1 






Intermediate verification 


B-2.3 


6 


Modules 


B-3.2 






Changes during development 


B-2.4 


9 


Operating system 


B-3.3 


4 




System reconfiguration 


B-2.5 


9 


Execution time 
Interrupts 

Arithmetic expressions 
Plausibility check 
Safe output 
Branches and loops 
Subroutines and procedures 
Nested structures 
Data structures 


B-3.4 
B-3.5 
B-3.6 
B-4.1 
B-4.2 
B-5.1 
B-5.2 
B-5.3 
B-5.5 


4 
4 


ii) Coding 


Intermediate verification 


B-2.3 


6 


Modules 


B-3.2 






Changes during development 


B-2.4 


9 


Execution time 
Interrupts 


B-3.4 
B-3.5 






Intermediate tests 


B-5.7 


6 


Arithmetic expression 


B-3.6 






Coding rules 


B-6.4 




Plausibility check 
Safe output 
Memory contents 
Error checking 
Branches and loops 
Subroutines and procedures 
Nested structures 
Addressing and arrays 
Data structures 
Dynamic changes 
Sequences and arrangement 
Comments 
Assembler/Compiler 


B-4.1 
B-4.2 
B-4.3 
B-4.4 
B-5.1 
B-5.2 
B-5.3 
B-5.4 
B-5.5 
B-5.6 
B-6.1 
B-6.2 
B-6.3 
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6.3.2 Use of the Recommendations 

6.3.2.1 At the outset of any safety related 
programming project those recommendations should 
be selected and recorded which apply to the intended 
programme development. The selection may include 
the change of priorities and further sub-divide into 
details of individual recommendations. 

6.3.2.2 In connection with particular problems it may 
be reasonable to modify the recommendations 
selected from Annex B, in order to meet the goal of 
overall simplicity and understandability. These 
modifications shall be documented, taking account of 
the following: 

a) During the selection procedure of the recom- 
mendations, the safety relevance of particular 
software parts should be considered; 

b) The more limiting recommendations should be 
selected and applied to those programme sec- 
tions which are more critical to the safety of 
the system; 

c) Programme sections of outstanding safety 
relevance should be clearly identifiable from 
the system and data structure used; 

d) The selection procedure should take into 
account the available testing facilities and the 
intended validation strategy. If important parts 
are programmed diversely, a different verifica- 
tion strategy may be used for those parts; and 

e) If difficulties arise during verification, a 
retrospective change of programming style 
may be necessary. 

6.4 Documentation 

6.4.1 During programme development the end of the 
design phase shall be marked by production of a 
formal document, the software performance 
specification {see M3 of F-l and F-3). This document 
serves as the basis for the formal design review and the 
subsequent programme coding. 

Sufficient detail shall be included so that programme 
coding can proceed without further design 
clarification. An outline of the suggested content is 
given in Annex C. 

6.4.2 In addition to the software performance 
specification, other documents may be required. They 
are used for both intermediate and final programme 
verification steps. Some of these documents relate to 
the first design steps. They are derived from the 
functional requirements specification and provide the 
basis for the software performance specification. 
Others are derived from this particular document and 
represent the basis for later coding. 

If the recommendations for the development 
procedure according to Annex B are met, appropriate 



documentation is provided as a by-product of 
programme development. 

6.4 .3 The aim is an integrated set of documents. Each 
document shall have a defined relationship to the other 
document and contain a well bounded subject-matter. 

6.4.4 Documentation formats should be selected 
according to the specific purpose, including: 

a) Narrative description; 

b) Arithmetic expressions; and 

c) Appropriate diagrams and drawings. 

As a general rule it is preferable to choose a graphical 
representation. The documentation itself shall follow 
the relevant standards. 

7 VERIFICATION 

7.1 Software Verification Process 

7.1.1 After the software functional requirements have 
been established and before the next phase begins, 
verification addresses the adequacy of the software 
functional requirements in fulfilling the safety system 
requirements assigned to the software by the computer 
system specification. 

7.1.2 After the design phase and before the next phase 
begins, verification addresses the adequacy of 
computer system software design as documented in 
the software performance specification to the software 
functional requirements. 

7.1.3 After the coding phase and before the next phase 
begins, verification addresses the compliance of the 
coded computer system software to the software 
performance specification as derived by the design 
phase. 

Each phase shall be completed by verification 
{see A-l). 

7.2 Software Verification Activities 

7.2.1 Verification Plan 

7.2.1.1 Concurrently with the phases of the software 
development cycle described above a software 
verification plan shall be established. The plan shall 
document all the criteria, the techniques and tools to 
be utilized in the verification process. It shall describe 
the activities to be performed to evaluate each item of 
software and each phase to show whether the 
functional and reliability requirements specification is 
met. The level of detail shall be such that an 
independent group can execute the verification plan 
and reach an objective judgement on whether or not 
the software meets its performance requirements. 

NOTE — The requirements for an independent group implies 
verification either by an individual or an organization which is 
separate from the individual or organization developing the 
software. The most appropriate way is to engage a verification 
team. 
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7.2.1.2 The verification plan shall be prepared by a 
verification team addressing: 

a) Selection of verification strategies, either sys- 
tematic, random or both, with test case selec- 
tion according to either required functions, 
special features of programme structure, or 
both (see Annex E); 

b) Selection and utilization of the software test 
equipment; 

c) Execution of verification; 

d) Documentation of verification activities; and 

e) Evaluation of verification results gained from 
verification equipment directly and from tests, 
evaluation of whether the reliability require- 
ments are met. 

The management of the verification team shall be 
separate and independent from the management of the 
development team. The members of the verification 
team shall have proven skill in the design and 
development of safety critical and safety related 
computer systems. 

7.2.2 Design Verification, Critical Reviews 

7.2.2.1 The design verification addresses: 

a) Adequacy of the software performance 
specification for the software functional 
requirements with respect to consistency and 
completeness down to and including the 
modular level; 

b) Decomposition of the design into functional 
modules and the manner of specification with 
reference to: 

1 ) feasibility of the performance required; 

2) testability for further verification; 

3) readability by the development and 
verification team; and 

4) maintainability to permit further evolu- 
tion; 

c) Aspects of quality requirements. 

In case of any non-conformance as mentioned above, 
the software design shall be updated to meet the 
requirements to ensure safety before going to the 
coding phase. 

7.2.2.2 The result of the design verification shall be 
documented in a report {see M5 of F-l and F-3). This 
report shall include: 

a) Items which do not conform to the software 
functional requirements; 

b) Items which do not conform to the design 
standards; and 

c) Modules, data, structures and algorithms 
poorly adapted to the problem. 

7.2.3 Coding Phase Verification 

The code verification activities begin with module 
testing and go up through the software by a bottom-up 



strategy. At the module level, the software is not yet 
integrated into the system, therefore it can be 
extensively tested. The purpose of module testing is 
to show that each module performs its intended 
function and does not perform unintended functions. 
A module integration test shall be performed to show 
at the earliest stage of development that all modules 
interact correctly to perform the intended function. 

Guidance for code verification activities is given in the 
software test specification. 

7.2.3.1 Software test specification 

The software test specification is one of the principal 
documents of the verification plan for the coding 
phase. This document shall be based upon a detailed 
examination of the software functional requirements 
and shall give detailed information on the tests to be 
performed addressing each of the components of the 
software (modules, their constituents and interfaces). 

The software test specification is based on a general 
description of the software being tested. The 
description is supplied by the design team. 

The software test specification shall include: 

a) Environment in which the tests are run; 

b) Test procedures; 

c) Acceptance criteria, that is a detailed defini- 
tion of the criteria to be fulfilled in order to 
accept modules and major software com- 
ponents on sub-system and system level; 

d) Error detection and corrective action proce- 
dures; and 

e) A list of all documents that should be produced 
during the code verification phase. 

7.2.3.2 Software test report 

The software test report shall present the results of the 
test programme described in the software test 
specification stating whether or not the software has 
achieved the performance requirements given in the 
software functional requirements. This standard (see 
M4 of F-l and F-3) shall allow the complete diagnosis 
of design and performance deficiencies. It shall also 
include the resolution of all software deficiencies and 
test discrepancies discovered during the test. 

The software test report shall include the following 
items both for the module and major design levels: 

a) Hardware configuration used for the test; 

b) Storage medium used and access requirements 
of the final code tested; 

c) Input test listing; 

d) Output test listing; 

e) Additional data regarding timing, sequence of 
events, etc; 

Conformance with acceptance criteria given in 
the test specification; and 
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g) Error incident log which describes the charac- 
ter of the error and the remedies taken by the 
design team. 

8 HARDWARE/SOFTWARE INTEGRATION 

The process of hardware/software integration is the 
combining of verified hardware and software modules 
into a system that is capable of performing specified 
functions. This process consists of four parts: 

a) Assembling hardware modules by intercon- 
necting wiring according to the system design 
drawings; 

b) Assembling software modules by a linkage 
processor; 

c) Loading the software into the hardware; and 

d) Verifying by testing that the hardware/ 
software interface requirements have been 
satisfied and that the software is capable of 
operating in that particular hardware environ- 
ment. 



8.1 System Integration Plan 

8.1.1 The system integration plan shall be prepared 
and documented in the integration requirements 
(see A-l) and verified against the safety system 
requirements. The system integration plan (see M2 
of F-l and F-3) describes the organizational and 
procedural aspects of the hardware/software 
integration. 

8.1.2 This plan shall specify the standards and 
procedures to be followed in the hardware/software 
integration and shall document those provisions of the 
overall quality assurance plan that are applicable to the 
system integration. 

8.1.3 The system integration plan shall discuss any 
constraints made by the specific design of the 
hardware and the software. The plan shall include the 
requirements for procedures and control methods 
covering: 

a) System configuration control; 

b) System integration; 

c) Integrated system verification testing; and 

d) Error resolution. 

8.1.4 In the process of verifying the individual 
hardware and software modules, certain aspects of the 
design of these modules may be better tested at the 
integrated system level. All interdependencies 
between the verification of the individual modules and 
the verification testing of the integrated system shall 
be documented in the system integration plan. 

8.2 Relationship of System Integration to 
Hardware and Software Development 

The system integration plan shall be prepared 
sufficiently early in the development process to allow 



any integration requirements to be included in the 
design of the hardware and software. 

8.3 System Configuration Control 

8.3.1 The system integration plan shall establish a 
library of software and hardware modules as the means 
for system configuration control. This library shall 
provide revision control for all hardware and software 
modules to be used in the system. 

83.2 Adequate procedures shall be established to 
implement this library function and shall provide for 
the following tasks of the library function: 

a) Procedure shall ensure that no module or 
revision is entered into the library until it has 
been verified; 

b) Procedure shall ensure that the system integra- 
tion is performed using the proper revision 
levels of the individual modules; 

c) Procedure shall provide for an index of the use 
of each module in the system so that the impact 
of future revisions to the modules can be 
adequately assessed; and 

d) Procedure shall be conducted in such a way 
that the overall quality assurance plan is met. 

8.4 System Integration Phase 

8.4.1 The specific procedures for the hardware/ 
software integration necessarily depend on the nature 
of the system design and cannot be included in this 
standard. However, such procedures shall be 
established and documented by the integration plan 
and shall cover the following activities: 

a) Acquisition of the proper modules using the 
library and procedures of 7.3; 

b) Integration of the hardware modules into the 
system (for example, module position, 
memory address, selection, interconnection 
wiring); 

c) Linkage of software modules and the loading 
of the software into the hardware; 

d) Preliminary functional test of the integrated 
system function (see 7.4.2); 

e) Documentation of the integration process and 
the system configuration that will be subjected 
to verification testing; and 

f) Formal release of the integrated system to 
verification testing. 

8.4.2 The testing performed in this phase of the 
hardware/software integration is the designer's 
functional test of the system. It is the system analogy 
to the debugging done by a programmer before he 
releases his software to be verified. If the resolution of 
any error requires a change to verified software or any 
design document, that error shall be reported 
according to the procedures established by 7.6. 
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8.5 Integrated System Verification 

8.5.1 The system verification is the process of 
determining whether or not the verified hardware and 
software modules have been properly integrated into 
the system and that the hardware and software are 
compatible and perform as a system as required by the 
integration requirements. 

8.5.2 The system shall be as complete as is practical 
for this testing. 

8.5.3 The test cases selected for system verification 
shall exercise all module interfaces as well as the basic 
operation of the modules themselves. Justification 
shall be provided in the system integration plan for the 
simulation of any part of the system or its interfaces. 

8.5.4 Integrated system verification shall be 
conducted in accordance with a formal test plan. The 
plan shall identify the tests for each computer system 
interface requirement. The integrated system test 
shall be developed and the test results evaluated by 
individuals who are familiar with the system 
specification and who did not participate in the 
development of the system. 

8.5.5 The level of independence provided between 
the designers and the system verifiers shall be 
sufficient to ensure that all communication between 
the two parties, whether for clarification or error 
reporting, is only conducted formally in writing at a 
level of detail which may be audited by persons not 
involved in the development of the system. 

8.5.6 Equipment used for system verification shall be 
calibrated. Quality assurance measures shall be 
established for software tools used for verification, 
commensurate with the importance of those tools for 
verification. 

8.6 Error Resolution Procedures 

8.6.1 Specific procedures for the reporting and 
resolution of errors shall be prepared as a part of the 
system integration plan. These procedures shall apply 
to all errors found during the system verification as 
well as those found during the integration functional 
test that require changes to verified software or system 
design documents. The procedure shall ensure that 
any required re-verification of hardware or software 
modules is performed and that the revision to the 
modules is carried out through the library procedures 
of 7.3. 

8.6.2 An evaluation of each error reported shall be 
made to determine whether the error was of such a 
nature that it should have been detected at an earlier 
phase (such as module testing) of the verification. If 
this is found to be the case, then an investigation of 
that earlier stage of the verification shall be conducted 



to determine whether any systematic deficiency of the 
verification exists. 

8.7 Integrated System Verification Test Report 

8.7.1 The results of the integrated system verification 
shall be documented in a test report (see M5 of F-l 
and F-3). This report shall identify the hardware and 
software used, the test equipment used and its 
calibration, the simulation of system or interface 
components, and any test results discrepancy found 
along with the corrective actions taken according 
to 7.6. The test results shall be retained in a form that 
is auditable by persons not directly engaged in the test 
programme. 

8.7.2 The resolution of all reported errors and the 
results of the subsequent evaluation shall be 
documented in sufficient detail and in a manner that is 
auditable by persons not directly engaged in the 
system development and verification programme. 

9 COMPUTER SYSTEM VALIDATION 

9.1 Genera] 

9.1.1 Testing shall be performed to validate the 
hardware and software as a system in accordance with 
the safety systems requirements to be satisfied by the 
computer system. The computer system validation 
shall be conducted in accordance with a formal 
validation plan (see M5 of F-l and F-3). The plan 
shall identify the validation for static and dynamic 
cases. 

9.1.2 The computer system shall be exercised by 
static and dynamic simulation of input signals present 
during normal operation, anticipated operational 
occurrences and accident conditions requiring 
computer system action. Each safety function should 
be confirmed by representative tests of each trip or 
protection parameter singly and in combination. 

9.1.3 It is recommended that' the tests be conducted 
so as to: 

a) Cover all signal ranges, and the ranges of 
computed or calculated parameters in a fully 
representative-manner; 

b) Cover the voting and other logic combinations 
comprehensively; 

c) Be made for all trip or protective signals in the 
final assembly configuration; 

d) Cover signals out of range; 

e) Ensure that accuracy and response times are 
confirmed and that correct action is taken for 
any equipment failure or failure combination; 
and 

f) Cover signals coupled with anticipated noise. 

9.1.4 In addition, the required input signals and their 
values, the anticipated output signals and the 
acceptance criteria shall be stated in the validation 
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plan. The computer system validation plan shall be 
developed and the results of the validation be 
evaluated by individuals who did notjaarticipate in the 
development phase. 

9.1.5 Equipment used for validation shall be 
calibrated. Proven hardware and software shall be 
used for validation. They should, however, be shown 
to be suited to their purpose. 

9.2 Computer System Validation Report 

9.2.1 The results of the computer system validation 
shall be documented in a report (see M6 ofF-1 
and F-3). This report shall identify the hardware and 
software used, the equipment used and its calibration, 
the simulation models used, and any discrepancies and 
corrective actions according to the modification 
procedure of 9. 

9.2.2 The report shall summarize the results of the 
computer system validation and shall assess the 
system compliance with all requirements. 

9.2.3 The results shall be retained in a form that is 
auditable by persons not directly engaged in the 
validation. Software tools used in the validation 
process should be identified as an item in the 
validation report. Simulations of the plant and its 
systems used for the validation shall be documented. 

10 MAINTENANCE AND MODIFICATION 

A formal modification control procedure shall be 
established including verification and validation. 

10.1 Modification Request Procedure 

For a modification to be considered, the following 
procedure shall be followed. 

10.1.1 A software modification request shall be 
generated, and uniquely identified stating: 

a) Reason for request; 

b) Aim; 

c) Functional scope; and 

d) Originator. 

The modification may be requested during the 
development phase because of a change of functional 
requirements caused by: 

a) Functional modification; 

b) Technological evolution; and 

c) Changes of operating conditions. 

The modification may be requested because of an 
anomaly report as a result of tests or change in the 
functional requirements. Modification for these 
reasons may cause a change in the software 
requirements document. If the modification is 
requested after delivery; it is then considered to be 
maintenance of the software. 



10.1.2 The modification request shall be evaluated 
independently, the result being either: 

a) Reject the request; in this case it is sent back 
with comments; 

b) Approve a request of minor importance and 
impact immediately if it is made during initial 
development after analysis; 

c) Require a detailed analysis resulting in 
software modification analysis report. This 
report shall be written by software personnel 
knowledgeable in the system software; and 

d) Accept the request. 

10.1.3 The following items shall be examined in the 
evaluation of the modification request: 

a) Technical feasibility; 

b) Impact upon hardware (for example, memory 
extension) or upon other equipment (for 
example, test systems) in which case the 
request for modification addressing this 
impact area must be documented for the equipment 

c) Impact upon software including a list of af- 
fected modules; 

d) Impact upon performance (including speed, 
accuracy, etc); 

e) Necessary effect for verification and valida- 
tion; the analysis of the software re-verifica- 
tion needed shall be documented in an 
auditable form; 

f) Set of documents to be reviewed. 

10.1.4 The software modification request is pending 
until the decision is made: 

a) To accept it (immediately, or after examina- 
tion of the software modification analysis 
report) and to execute it, or 

b) To reject it and justify the rejection. 

10.2 Procedure for Executing a Modification 

10.2.1 For modifications on site, the software 
supplier should have access to a test configuration 
which is identical to the real system in all relevant 
aspects (including installed machine, translator, 
testing tools, plant simulator, etc) to ensure the 
validity of the modifications. 

10.2.2 A modification procedure depends upon the 
level at which it is introduced: 

a) For a change of the software functional 
specification, the whole software development 
process for any part of the system impacted by 
the change shall be re-examined; 

b) A change during the development phase shall 
be reviewed in terms of its potential impact 
upon correspondhrgTower levels; and 

c) The modification shall be carried out accord- 
ing to the rules given in 5. 
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10.2.3 After implementation of the modification, the 
whole or part of the verification and validation process 
described in 6.1 and 8, shall be performed again 
according to the software modification analysis 
{see 9.1.3). 

10.2.4 All the documents affected by the 
modification shall be corrected and refer to the 
identification of the software modification request. A 
software modification report shall sum up all the 
actions made for modification purposes. 

All these documents shall be dated, numbered and 
filed in the software modification control history for 
the project. 

10.2.5 The testing and verification of modification in 
software shall be performed in separate identical spare 
system. After successful testing and verification, the 
modified software shall be ported to target system. 

10.3 Maintenance 

The reasons for maintenance include: 

a) An anomaly report; 

b) A functional requirements change after 
delivery; 

c) Technological evolution; and 

d) A change in operating conditions. 

10.3.1 In case of an anomaly, an anomaly report shall 
be written giving the symptoms, the system 
environment and system status at the time at which the 
anomaly was discovered and the suspected causes. 
Anomaly correction requires the generation of a 
software modification request, the execution of which 
shall follow the procedure described in 9.1. 

10.3.2 In case of a change in software functional 
requirements or in operating conditions, the whole 
software development process shall be re-examined 
for that part of the system impacted by the change. 

10.3.3 Any new hardware requirements and 
capabilities shall be examined with respect to their 
potential impact on the software systems. This 
evaluation should include all hardware considerations 
reviewed in the original software design. If it can 
be shown that the new system does not impact the 
software requirements, a simplified procedure may be 
used to implement the modification either at the design 
or coding phase. 

10.3.4 In all cases, after implementation of the 
modification upon the in-the-field equipment, a 
field document shall be issued which gives the date 
of the implementation and the result of the 
specified observations. This document shall be filed 
in the software modification control history for the 
project. 



11 COMMISSIONING AND OPERATION 

11.1 Computer System 

11.1.1 Commissioning Tests 

11.1.1.1 A test programme shall be provided to verify 
the integrity of the installed computer-based safety 
system with respect to response, calibration, 
functional operation and interaction with other 
systems. 

11.1.1.2 A commissioning test plan, consisting of 
acceptance criteria, test cases and test environment 
shall be established {see M6 of F-l and F-3). 

11.1.13 A commissioning test report presenting test 
results and conformity to acceptance criteria shall be 
established {see M7 of F-l and F-3). 

11.1.2 Man-Machine Interaction 

11.1.2.1 To allow man-machine interaction, operator 
control of computer functions may be required. These 
devices shall not provide the capability to alter the 
stored computer programme logic. 

11.1.2.2 An appropriate procedure and/or locking 
device shall be established to prevent the operator 
inadvertently changing parameters that can affect the 
set points of the safety system. 

11.1.2.3 All the actions performed by the operator 
through the operator control shall be documented by 
suitable means. 

11.2 Operator Training 

11.2.1 Training Programme 

In order to achieve safe plant operation, operator 
behaviour is as important as equipment reliability. 
Therefore an operator training programme shall be 
provided both for plant operators and instrumentation 
and control specialists consistent with the complexity 
of the protective functions implemented. The training 
programme shall provide for normal and abnormal 
operation. All operator interfaces of the computer 
system shall be included in the training programme. 
Specific training in the recognition of hardware and 
software abnormalities should also be included in the 
programme. The training programme shall also 
include description of the hardware and software. 
Procedure for stopping and re-starting the system and 
procedure for changing software constants like alarm 
limits and keywords related to the plant signals shall 
be well documented. 

11.2.2 Training Plan 

1 1.2.2.1 A training plan consistent with the principles 
of the training programme shall be established {see M6 
ofF-landF-3). 

1 1.2.2.2 A user manual shall be provided for the plant 
operator {see M6 of F-l and F-3). The user manual 
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should define each operator interface device. Each 
function of each device shall be explained and 
illustrated in accordance with its complexity. 

11.2.3 Training System 

11.2.3.1 Operator training shall be conducted on a 
training system which is equivalent to the actual 
hardware/software system. The plant stimulus to this 
system shall be provided by a test system capable of 
simulating normal and abnormal plant conditions. 

11.2.3.2 Furthermore the training system should 
provide training facilities for each operator interface 
device. A computerized simulator may be used for 
this purpose. 

11.3 Software Requirements for Periodic Testing 

11.3.1 Test Programme 

A programme for periodic tests of the safety systems 
including applicable functional tests, instruments, 



checks, verification of proper calibration and response 
time tests shall be defined. 

113.2 Test Requirements 

The tests shall verify the basic functional capabilities 
of the software periodically including: 

a) Test of all basic safety functions; 

b) Special testing to be used to detect failures that 
cannot be revealed by self-checking provisions 
of the safety systems or by alarm or anomaly 
indications; and 

c) Tests of the major non-safety related functions. 

113.3 Auxiliary Device Requirements 

The software dedicated to auxiliary devices for 
periodic testing of the safety systems need not be 
designed to comply with all software safety 
requirements. Their quality should correspond to the 
quality of verification tools as mentioned in 8. Test 
data should be selected according to E-4.2. 



ANNEX A 

(Clauses 1.1, 5.1.2, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 7.1.3 and 8.1.1) 
SYSTEM DEVELOPMENT LIFE CYCLE AND DETAILS OF SOFTWARE REQUIREMENTS 



A-l SYSTEM DEVELOPMENT LIFE CYCLE 

The system development life cycle is illustrated in 
Fig. 1, which shows the relationship of the designed 
implementation activities to the verification and 
validation activities. 

A-2 DETADLS OF SYSTEM REQUIREMENTS 

A-2.1 Computer System Specification 

A-2.1.1 The purpose of the computer system 
specification is to: 

a) State the overall purpose of the software with 
a definition of explicit limits and with a state- 
ment of what the software must not do; 

b) List volume and throughput expectations of 
the software and state explicitly which are 
merely target figures or goals and which are 
absolutely necessary for the software system; 

c) Safeguards against entry of viruses; 

d) State qualitative expectations of the system 
(for example, required accuracy) separated 
into absolute and approximate objectives; 

e) State objectives relative to policy, tradition, 
industrial practices and management direc- 
tives; 

f) Classify the objectives according to priority. 

A-2.1.2 If the computer system is used for 
supervising and controlling nuclear reactor, the 



specification describes functions dedicated to the 
prevention of the release of radioactivity under 
accident conditions, and their initiation conditions. 
The document should include function and initiation 
conditions for: 



a) 
b) 

c) 



d) 



Emergency shut down; 
Other safety functions, the necessary calcula- 
tions, their physical background; 
Functions that prevent plant damage, the 
necessary calculations, their physical back- 
ground; and 
Functions that have minor safety relevance. 



The description should state the relationship of these 
functions to the total plant concept and the control 
function executed by other systems. 

A-2.2 Computer System Configuration 

A-2.2.1 The quantitative reliability requirements for 
individual actions,' functions and sequences of action 
or for handling particular disturbances, transients and 
accident situations should be considered, taking 
account of classes of safety relevance. 

The hardware and software shall comply with the 
single failure criterion. 

A-2.2.2 To avoid common-mode failure effects and 
to increase system reliability, the following factors are 
relevant: 
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a) Defence-in-depth; 

b) Graceful degradation; 

c) Management of failures in general; 

d) Functional diversity and if necessary software 
diversity; and 

e) Spatial separation and modularization, 
decoupling, logical separation. 

A-2.2 .3 The design shall take account of: 

a) Interaction between the different blocks and 
separate units; 

b) Hierarchy of functions ; 

c) System structuring criteria; 

d) System software configuration; 

e) Interface design principles; and 

f) System adaptability, changeability and the 
expansion capability of interfaces. 

A-2J Man- Machine Interaction 

A-23.1 The basic principles include: 

a) No computer system failure shall inhibit 
appropriate human control actions; 



b) 
c) 



d) 



e) 
f) 



g) 



h) 



J) 



Man-machine interfaces shall be identified; 

Formal procedures and a clear syntax for 

human interactions with the computer system 

shall be defined; 

The human procedures within the system, 

which are likely to be bottlenecks or are likely 

to cause undue problems with the system such 

as human operation, which could enter errors, 

shall be identified; 

The computer system shall check any manual input 

for syntactic correctness and semantic plausibility; 

Inappropriate operator control actions should 

be signalled; 

From identified interfaces and problems areas, 

a description of human engineering factors, 

which could have a significant effect on human 

performance, shall be derived; 

The human procedures that will require 

significant training or elaborate aids shall be 

identified; and 

The entire system shall be reviewed and 

analyzed to ensure that the automated portions 
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of the system are designed to aid and support 
the human portions and not the reverse. 

A-2.3.2 The requirements for human actions to the 
computer system include: 

a) The operator shall be able to check basic sys- 
tem functions on-line; 

b) No modification for software shall be made 
during plant operation, without following a 
strictly controlled procedure; 

c) The procedures for introduction, modification 
and display of parameters shall be exactly 
defined, simple and easy to comprehend; 

d) Appropriate 'menu' techniques shall be 
provided; and 

e) Manual interaction shall not delay basic safety 
actions beyond specified limits. 

A-2.3.3 The requirements for computer system 
displays include: 

a) Computer system shall not mislead the 
operator; 

b) Computer system shall report its own defects 
and failures to the operator; 

c) Use of colours, flashing signals, alerting sig- 
nals etc. shall follow a clear scheme; and 

d) Information displayed and its format shall 
follow ergonomic principles. 

A-2.4 Items Relating to Interfaces (Other than 
Man-Machine Interface) 

The following items should be considered: 

a) Independency and decoupling; 

b) Prevention of transmission failures and of 
failure propagation; 

c) Strict control of interactions between systems 
or sub-systems of different safety relevance, 
including handshake mechanisms, com- 
munication protocols, failure checks, message 
formats, and message throughput; 

d) Resource constraints; and 

e) Appropriate reference to more detailed docu- 
ments. 

The incorporation of the computer systems in the 
safety systems and their relationship with the safety 
actuation systems shall be precisely described. 

A-2.5 Description of System Functions 

A-2.5.1 Thecomplete list of system functions shall be 
given. The number of items to be described depends 
on the complexity of the function. The description 
shall include as a minimum: 

a) Aim of each function; 

b) Relevance to the system reliability; and 

c) All input/output variables. 



A-2.5.2 All variables necessary to execute the 
function shall be stated with regard to the following 
items: 

a) Input domain and output range; 

b) Relationship between the internal repre- 
sentation of the variable and its corresponding 
engineering units value; 

c) Input accuracy and noise limits; and 

d) Output accuracy. 

A-2.53 Particular emphasis shall be placed on the 
description of functions with regard to safety, and 
those requiring a complex software design, and those 
needed to control or govern complex physical 
mechanisms. 

A-2.5.4 A detailed description of all system functions 
shall be provided relating them to each other and to 
system inputs and outputs. Diagrams shall be 
provided depicting functional and input/output 
relationships. 

The description of such functions shall include, as far 
as applicable: 

a) Reasons for particular functions; 

b) Conditions which cause each function to 
operate (accident detection); 

c) Sequences of tasks, actions and events; 

d) Starting conditions, systems status at initiation 
of function; 

e) Further possible extensions of that function; 
and 

f) Details of the verification procedure. 

A-2.5.5 The performance of the system shall be 
stated, including: 

a) Worst case, best case, planned level of perfor- 
mance in any respect, including accuracy; 

b) Irrational input signals due to noise or sensor 
failure; 

c) Timing; 

d) Other existing constraints and compulsory 
conditions; 

e) All calculations particular to the application or 
application-dependent data manipulations that 
must be made on the data; 

f) Input/output handling functions, synchroniza- 
tion communication protocol; and 

g) Input validation functions such as format 
validation, field validation, logic checks and 
source validation. 

A-2.5.6 The system data structure and relationships 
should be described including: 

a) Data base characteristics, maintenance and up- 
dating; 

b) All information retrieval functions; 

c) Identification of all data elements that will be 
required to arrive at the specified output; 
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d) Classification of related data > elements into 
groups; 

e) Data group activity relationships, relationship 
between each data group and the inputs and 
outputs of the system; and 

Classification of data groups which are more 
critical than others in terms of access require- 
ments. 

A-2.6 Description of Constraints Between 
Hardware and Software 

A-2.6.1 The following items shall be described: 

a) Operating characteristics in general (word 
length, exchange types, speed etc); in many 
cases a reference to the equipment manufac- 
turer manuals is sufficient; 

b) Special equipment operating characteristics 
(particular drivers, data-communications 
equipment, etc); 

c) Arithmetic constraints; 

d) Requirements of proven software packages; 

e) Requirements of hardware self-supervision; 
and 

f) At least a reference to the hardware require- 
ments document shall be made. 

A-2.6.2 The postulated failure causes of the hardware 
should be carefully examined to determine where the 
principle for diversity could be used effectively to 
avoid common-mode failures. This diversity may be: 

a) Functional diversity in which several different 
means are used to accomplish a particular task; 

b) Equipment diversity in which hardware from 
different suppliers is used. 

A-2.6.3 The reciprocal requirements between 
hardware and software shall be determined with 
respect to failure detection and reaction on failure 
indications. 

Documentation of all hardware requirements which 
impact software is necessary to provide the basis for 
hardware/software integration and computer system 
validation. The interface between software or 
hardware at one level of safety significance and at 
higher levels shall be described. 

A-2.6.4 In some software systems it may be advisable 
to describe the following items in addition to those 
already mentioned: 

a) S patial separation of softw are and modulariza- 
tion due to the hardware structure chosen; 

b) Effects of the multi-processor structure on 
software, effects of the linkage between the 
processors; 

c) Time-effects of digital processing; 

d) Real time monitors; and 

e) System expansion capabilities and system 
adaptability. 



A-2.7 Description of Special Operating 
Conditions 

At least the following conditions shall be considered: 

a) Plant commissioning and refuelling (in case of 
reactors); 

b) System initialization, including setting the 
system into operation, providing the necessary 
starting values etc; 

c) System switch-off, removal from service; 

d) Re-try procedures implemented in the system; 

e) Graceful degradation if errors in the software 
are recognized and if hardware failures are 
detected, in particular if certain input or output 
devices are not available; 

f) System re-configuration and re-initialization 
after the whole system or some parts have been 
out of service; and 

g) Reference to necessary operator actions. 

A-2.8 Self-Supervision 

A-2.8.1 Appropriate automated actions should be 
taken at failures considering the following factors: 

a) Failures shall be identified to a reasonable 
degree of detail and isolated to the narrowest 
environment; 

b) Fail-safe output shall be guaranteed as far as 
possible; 

c) If such a guarantee cannot be given, system 
output shall violate only less essential safety 
requirements; 

d) The consequences of failures shall be mini- 
mized; 

e) Remedial procedures, such as, fall back, re-try, 
system recovery, should be considered for 
inclusion; 

Reconstruction of obliterated or incorrectly 

altered data may be tried; and 
g) Information on failures shall be provided for 

the operating staff. 

A-2.8.2 The system shall be designed such that 
appropriate self-supervision is feasible. Design 
principles used to assist this include: 

a) Modularization; 

b) Intermediate plausibility checks; 

c) Use of redundancy and diversity; diversity 
may be implemented as functional diversity or 
software diversity; 

d) Provision of sufficient execution time and 
memory space for self-checking purposes 
as specified in the system specification 
document; 

e) Incorporation of permanent test facilities; and 

f) Failure simulation may be used to confirm the 
adequacy of self-supervision features. 
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A-2.8.3 System self-checking shall not prevent 
timely system reactions in any circumstance. 

A-2.9 Presentation of Software Functional 
Requirements 

A-2.9.1 The software functional requirements shall 
be presented in a manner, which is easy to understand 
for all user groups. The presentation shall be 
sufficiently detailed, free from contradiction, and 
non-redundant as far as possible. 

The document shall be free of implementation details, 
complete, consistent and up-to-date. 



A-2.9.2 The software requirements document shall 
distinguish clearly between essential performance 
requirements and less stringent targets. 

A-2.9.3 The software requirements document is 
intended to be used by: 

a) Authors, that is, plant specialists; 

b) Customer, client or final user; 

c) Software system development team; 

d) Software system verification team; and 

e) Assessors and licensing personnel. 



ANNEX B 

(Clauses 1.3, 6.1.2, 6.2.4, 6.3.1 and 6.4.2) 

DETAILED RECOMMENDATIONS FOR THE DEVELOPMENT (DESIGN AND CODING) OF 

SAFETY RELATED SOFTWARE 



B-l The recommendations are listed in the following 
clauses. The indicated priority or importance shows 
the significance of the individual requirements. T 
means the highest significant, '3' the lowest. A project 
should select recommended criteria according to the 
priority indicated for each main heading and 
sub-heading in order. 

If the implementation of a specific requirement can be 
facilitated by computer hardware, a special 
programme or the operating system, this is usually 



marked by 'x'. If in addition to this a minor help can 
be used this is marked additionally by 4 0\- 

A reference is given in the 'Check' column to the 
material which allows confirmation that a 
recommendation has been met, as follows: 

a) 'D' stands for documentation; 

b) 'C* for written code; 

c) 'H' signifies verification is hardly possible; 
and 

d) T' means verification is possible during 
programme testing. 
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B-2 DESIGN PROCEDURES 
B-2.1 Changeability 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


a 


Software design shall easily allow changes 


2 






X 






D 


Good against — Necessity of 
complete re-design at late 
development stages 


aa 
ab 
ac 


At an early design stage it should be identified which 
characteristics of the software to be developed and its 
functional requirements are likely to change during its 
life cycle 

During further design stages modules should be 
chosen such that the most probable modifications 
result in the change of one or two modules only 

Modifiability should be carefully counterbalanced with 
resulting overhead in run time and memory space 


2 

2 
1 






X 

X 

X 






D 

D 
D 


Good for — Reaching flexibility 

Good for — Ease of modifications 

Good against — Getting too bulky 
systems 



^ B-2.2 Top-Down Approach 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 




b 


A top-down approach shall be used in design 


2 








X 




D 


Good against — Design errors 

generally 

Good for — Completeness of design 


ba 
bb 

be 
bd 
be 


General aspects should precede specific ones 

At each level of refinement the whole system should 
be completely described and verified 

Areas of difficulty should be identified as far as 
possible at an early stage in the design procedure 

Principal decisions should be discussed and 
documented as soon as possible 

After any major decision affecting other system parts, 
the alternatives should be considered and their risks be 
documented 


2 
3 

3 
3 
3 








X 
X 

X 
X 
X 




D 
D 

D 
D 
D 


Good for — Consistency of the 
system and completeness of design 

Good for — Consistency of the 
system and finding problem areas as 
early as possible 

Good for — Coordination of 
programming 

Good against — Running in to difficulties 
at the end of the development 

Good against — Duplicating work 
Good for — Careful design 



u> 



Item 



bf 



bg 



bh 



bi 



bk 



bl 



Recommendation 



Consequences for other system parts which are 
implied by individual decisions should be identified 

The interval between levels should be small enough 
to permit a clear understanding of the decision process 
involved within the step 

The programme design and development should 
proceed using one or more higher level descriptive 
formalism, such as used in mathematical logic, set 
theory, pseudo code, decision tables, logic diagrams 
or other graphic aids or problem oriented languages 

As far as possible automatic development aids should 
be used 

Documentation should be such that the specifier is 
able to understand and check both the design and the 
programme 

Coding should be among the final steps taken 



Priority or 
Importance 



Realization by or in, or with the Help of 



Operating 
System 



Special 
Programme 



User 
Programme 



Programme 
Document 



O 



Hardware 



Check 



D 
C 



H 



Good Against/ Good for 



Good against — Duplicating work 
Good for — careful design 

Good against — Errors due to too 
large steps 



Good against — Misinterpretation or 
inaccuracy 



Good against — Human mistakes 
Good for — Saving effort 

Good for — Maintenance and 
consistency with specification 



Good against — Inconsistencies 



B-2.3 Intermediate Verification 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


c 


The intermediate product shall be continuously 
verified (see A-l) 


I 








X 




D 


Good for — Finding errors as soon 
as possible, completeness of design 


ca 
cb 
cc 

cd 


It should be shown that each level of refinement is 
complete and consistent in itself 

It should be shown that each level of refinement is 
consistent with the previous level 

Consistency checks should be made by neutral 
personnel 

These personnel should only mark deficiencies and 
not recommend any action 


1 
1 
3 

i 








X 
X 
X 
X 




D 
D 
H 
H 


Good against — Necessity of later 
changes 

Good against — Forgetting aspects 

Good against — Common errors 
with programming 

Good against — Personal 
identification with the programme 
Good for — Maintaining critical 
attitude 



B-2.4 Changes During Development 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in,, or with the Help of 


Good Against/ Good for 


Operating 

System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


d 


Changes which are necessary during programme 
development shall begin at the earliest design stage 
which is still relevant to the change 


1 








X 




D 


Good against — Introducing new 
errors due to changes 
Good for — Avoiding hidden far 
distant effects 


da 
db 

dc 

dd 

de 


Changes should proceed from the general stage to the 
more specific stages 

If any module is changed, it should be re-tested 
according to the principles described earlier, before it 
is re-integrated into the system 

In addition the environment of the changed module 
should be re-tested, as far as it is affected by the 
change 

Documentation of major changes should include the 
requirements, code parts, data areas, control flow 
characteristics and time aspects that were affected or 
not affected 

Changes affecting already tested parts or the work of 
other persons should be evaluated and reviewed prior 
to incorporation 


2 
1 

1 

2 

2 






X 

O 


X 


X 
X 

X 

X 

X 




D 

D 
C 

D 
D 

D 


Good for — Recognizing all effects 
of the change 

Good against — Hidden errors in 
module due to change 

Good against — Hidden errors in 
module environment due to change 

Good for — Traceability of change 
effects 

Good against — Hidden far distant 
effects 



NOTE — This procedure is valid for changes that affect the work of only one person and for modifications that affect the whole system. 



B-2.5 System Re-configuration 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


e 


The experience gained with any system to be adapted 
for new applications shall be taken into account 


1 







X 







D 


Good for — Statistical verification 


ea 


The state of the system should be assessed before 
adaptation 


1 







X 


X 




D 


Good against — Neglecting usable 

parts 

Good for — Recognizing failed parts 



Item 


Recommendation 


Priority or 
Importance 




Realization by or in 


, or with the Help of 




Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


eb 


One should rather try to use system parts or modules 
with extensive operating experience than to formally 
verify new ones 


2 






X 






D 


Good against — Unnecessary 
additional effort 


ec 


Decided changes or amendments should proceed as 
recommended in B-l (b) and B-l (d) 


1 






X 


X 




D 


Good for — Getting a clean system 


ed 


At code level each change should be made separately 


2 






X 






D 


Good for — Identifying errors soon 


ee 


Already verified parts or modules should be left 
unchanged 


2 






X 






C 


Good against — Producing new 

errors 

Good for — Saving verification 

effort 



B-3 SOFTWARE STRUCTURE 
B-3.1 Control and Access Structure 



S3 

O 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


a 


Programmes and programme parts shall be grouped 
systematically 


1 


O 




X 




O 


D 


Good for — Clear system structure 


aa 
ab 


Specific system operations should be performed by 
specific parts 

The software should be partitioned so that aspects 
which handle such functions as: 

a) computer external interfaces (for example, 
device driving, interrupt handling); 

b) real time signals (for example, clock); 

c) parallel processing (for example, scheduler); 

d) store allocation; 

e) special functions (for example, utilities); 

mapping standard functions on to the particular 

computer hardwire; 
are separated from application programmes with 
well defined interfaces between them 


1 

2 




o 


O 


X 
X 




O 


D 
C 

D 
C 


Good for — Testability 

Good for — Clear system structure, 
testability 



VI 

SO 

00 






Item 


Recommendation 


Priority or 
Importance 




Realization by or in 


, or with the Help of 




Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


ac 


The programme structure should permit the 
implementation of anticipated changes with a 
minimum of effort (see B-2.1) 


2 








X 




D 


Good for — System adaptability 


ad 


it should be made clear which structuring methods are 
being used 


1 








X 




D 


Good for — Understandability 


ae 


In one processor the programme system should work 
sequentially, as far as possible 


1 


X 




X 






C 
D 


Good against — Confusion due to 
timing problems or different 
interrupt sequences 


of 


A programme or a programme part should be broken 
down into clear and intelligible modules when it 
contains more than 100 executable statements 


1 


O 




X 






C 
D 


Good for — Understandability 



B-3.2 Modules 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


b 


Modules shall be clear and intelligible 


1 


O 




X 


O 




D,C 


Good for — Understandability 


ba 
bb 

be 
bd 


Each module should correspond to a specific function 

A module should have only one entry. Although 
multiple exits may be sometimes necessary, single 
exits are recommended 

No module should exceed a limit specified for the 
particular system (for example, 50 or-100 statements, 
or the amount of coding which can be placed on one 
page. Only under special circumstances are longer 
modules allowed) 

The interfaces between modules should be as simple 
as possible, uniform throughout the system and fully 
documented 


1 
1 

2 
1 






X 

X 
X 

X 






D 
C 
C 

C 

C 
D 


Good for — Testability 

Good for — Ease of verification 

Good against — Bulky modules 
Good for — Meeting ergonomic 
facts 

Good against — Errors in interfaces, 
which are normally difficult to detect 
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Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


be 

bf 


The number of input and output parameters of 
modules should be limited to a minimum 

It should be clearly stated which interface data are 
only used, only defined or re-defined 


1 

2 






X 


X 




C 

D 

D 
C 


Good against — Errors in interfaces, 
which are normally difficult to detect 

Good for- — Understanding meaning 
of parameters 



B-3.3 ( 


Operating System 


















Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Program 
Document 


Hardware 


Check 


c 


Operating system use shall be restricted 


I 


X 




X 




X 


D 


Good against — Failures due to 


ca 


Only thoroughly tested operating systems should be 
used; preferably the existing operating experience 
should be quantitatively known 


1 


X 










D 


operating system errors 

Good for — Ease of system 

verification 

Good against — Hidden errors 


cb 


If possible no operating system should be used 


1 






X 




X 


C 


Good for — Analytical verification 


cc 


If an operating system is considered necessary its use 
should be restricted to a few simple functions 


1 


X 




X 







C 


Good for — Getting a thoroughly 
tested operating system 


cd 


It should contain only the necessary functions 


1 


X 











D,C 


Good against — Dead code 


ce 


One particular operating system function should be 
called always in a similar way 


2 






X 




O 


C 


Good for — Statistical verification 
due to frequent call 


cf 


Device drivers should be taken from the operating 
system rather than specially developed 


2 


X 








X 


C 


Good against — Additional 
programming and test effort 


eg 


Operating system functions should be rigorously 
defined and should have well defined interfaces 


1 













D 


Good against — Misunderstanding 
during using 


ch 


If a dedicated operating system or a dedicated part is 
developed for a special safety application, these 
recommendations should be followed 


1 


X 




O 




X 


D 
C 


Good for — Ease of verification 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


ci 
ck 


New releases should be treated according to B-2.4 and 
B-2.5 

Other standardized programmes or programme parts 
should be treated as operating systems 


1 


X 






X 


X 




D 
C 

D 


Good against — Introducing new 
errors 

Good for — Statistical verification 
due to frequent call 



B-3.4 Execution Time 






Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


d 


Technical process behaviour influence on execution 
time shall be kept low 


1 






X 






D 
T 


Good against — Unintelligible 
timing problems 


da 
db 

dc 
dd 

de 

df 


The execution time of any system or part of a system 
under peak load conditions should be short compared 
to the execution time beyond which the system safety 
requirements are violated 

The results produced by a sequential programme shall 
not be dependent on either 

a) the time taken to execute the programme, or 

b) the time (referenced to an independent 'clock') at 
which execution of the programme is initiated 

Execution of sequential programmes which receive or 
transmit data from/to other sequential programmes 
shall be synchronized with those other programmes 

The programmes should be designed so that 
operations are performed in a correct sequence 
independent of their speed of execution 

Run time differences depending on input parameters 
should be small 

Run time differences depending on input parameters 
should be documented 


1 

1 

1 
1 

1 

2 




X 
X 


X 
X 

X 

X 

X 
X 


X 


X 


T 

D 
T 

C 

D 

T 
D 


Good against — Necessity of late 
design changes 

Good against — Unintelligible 
timing problems 

Good against — Unintelligible 
timing problems 

Good against — Synchronization 
problems and run time problems 
Good for — Analysis 

Good for — Ease of run time 
estimation and run time verification 

Good for — Ease of run time 
estimation and run time verification 



B3 
00 

§ 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


dg 
dh 


Code parts for which execution time depends on input 
parameters should be short 

The amount of parameters read during one 
computation cycle should be constant 


3 

3 






X 
X 






C 

D 
C 

T 


Good for — Reaching de 

Good for — Keeping run time 
differences short 
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B-3.5 ] 


interrupts 


















Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 

System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


e 


The use of interrupts shall be restricted 


1 


X 




X 




X 


C 

D 


Good against — Synchronization 
problems and run time problems 
Good for — Analysis 


ea 


Interrupts may be used if they simplify the system 


1 


X 




X 






C 
D 


Good for — Ease of understanding 
of special configurations 


eb 


Software handling of interrupts must be inhibited 
during critical parts (for example, time critical, critical 
to data changes) of the executed function 


1 


X 




X 




X 


C 
D 


Good against — Synchronization 
problems and run time problems 
Good for — Analysis 


ec 


If interrupts are used, parts not interruptable should 
have a defined maximum computation time, so that 
the maximum time for which an interrupt is inhibited 
can be calculated 


1 


X 




X 






C 
D 
T 


Good against — Run time problems 


ed 


Interrupt usage and masking shall be thoroughly 
documented 


1 


X 






X 


X 


D 


Good for — System validation 



B-3.6 Arithmetic Expressions 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


f 


Simple arithmetic expressions shall be used instead of 
complex ones 


2 






X 






C 
D 


Good against — Side effects 
Good for — Easy testing 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


fa 
fl> 
fc 


Decisions should not depend on voluminous 
arithmetic calculations 

As far as possible, simplified previously verified 
arithmetic expressions should be used 

If voluminous arithmetic expressions are used, they 
should be coded so that their consistency with the 
specified arithmetic expression can be shown easily 
from the code 


2 
2 
3 






X 
X 
X 






C 

D 

C 
D 

C 


Good for — Finding reverse function 
calculating path expressions 

Good for — Showing relationship 
between intended function and code 

Good for — Programme analysis 



B-4 SELF-SUPERVISION 
B-4.1 Plausibility Checks 






Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


a 


Plausibility checks shall be performed (defensive 
programming) 


2 






X 






C 

D 


Good against — Yet undetected enors 
Good for — Statistical verification 


aa 

ab 

ac 
ad 


The correctness or plausibility for intermediate results 
should be checked as often as possible, at least to 
within a small percentage of computer capacity 
(redundancy) 

Where safety related results are involved identical 
results should be evaluated, using different methods 
(diversity) 

Re-try procedures should be used 

The ranges of: 

a) input variables; 

b) output variables; 

c) intermediate parameters; 

d) should be checked, including array bound 
checking 


2 

2 

3 
2 






X 

X 

X 
X 






C 
D 

C 
D 

C 
D 
T 

C 
D 


Good against — Yet undetected errors 
Good for — Statistical verification 

Good against — Yet undetected errors 
Good for — Statistical verification 

Good against — Sporadic hardware 
faults 

Good against — Yet undetected errors 
Good for — Statistical verification 



1 



B-4.2 Safe Output 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or ith the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


b 


If a failure is detected the system shall produce a well 
defined output 


1 






X 






D 

T 


Good against — Fault propagation 


ba 

bb 
be 

bd 


If possible, complete and correct error recovery 
techniques should be used 

Even if correct error recovery cannot be guaranteed, 
failure detection must lead to well-defined output 

If error recovery techniques are used the occurrence 
of any error shall be reported 

The occurrence of a persistent error affecting the 
system function shall be recorded 


3 
1 

1 


X 
X 




X 

X 
X 

X 




O 


C 
D 
T 

D 
T 

D 
T 

D 
T 


Good against — System breakdown 
due to minor failures 

Good for — Equipment safety 

Good against — Accumulation of 

errors 

Good for — Early error removal 

Good against — Accumulation of 

errors 

Good for — Early error removal 



00 



w 



B-4.3 Memory Contents 



Item 



Recommendation 



Priority or 
Importance 



Realization by or in, or with the Help of 



Operating 
System 



Special 
Programme 



User 
Programme 



Programme 
Document 



Hardware 



Check 



Good Against/ Good for 



Memory contents shall be protected or monitored 



O 



O 



D 
T 



Good against — Unauthorized 
changes of a licensed system 



cb 



Memory space for constants and instructions shall be 
protected or supervised against changes 



Unauthorized reading and writing should be 
prevented 

The system should be secure against code or data 
changes by the plant operator 



O 



O 



O 



O 



D 
T 



D 
T 



Good against — Propagation of 
addressing errors or hardware faults, 
including intermittent faults 

Good against — Propagation of 
addressing errors or hardware faults, 
including intermittent faults 

Good for — Maintaining system 
integrity in its licensed form 



-J 



B-4.4 ] 


Error Checking 


















Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


d 


Error checking shall be performed at a detailed coding 
level 


1 






X 






C 
T 


Good against — Failure propagation 


da 


Counters and reasonableness traps (relay runners) 
should insure that the programme structure has been 
run through correctly 


1 




O 


X 






C 

T 


Good against — Specific control 
flow errors, intermittent hardware 
faults 


db 


The correctness of any kind of parameter transfer should 
be checked, including parameters type verification 


1 


O 




X 




X 


C 
D 


Good against — Errors in interface 
design, data flow design errors 


dc 


When addressing an array its bounds should be 
checked 


1 


o 




X 




X 


C 
D 
T 


Good against — Data flow errors, 
too high loop repetition numbers 


dd 


Called routines should check whether the calling 
module is entitled to do so 


3 






X 






C 
D 
T 


Good against — Control flow design 
errors 


de 


The run time of critical parts should be monitored (for 
example, by a watchdog timer) 


2 


X 




X 




X 


D 
T 


Good against — Control flow design 
errors, too high loop repetition 
numbers 


df 


Assertions should be used 


3 






X 






C 
D 


Good for — Plausibility of 
intermediate results 



B-5 DETAILED DESIGN AND CODING 
B-5.1 Branches and Loops 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 

System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


a 


Branches aiid loops should be handled cautiously 


1 






X 






C 
D 


Good for — Understandable and 
verifiable control flow 


aa 


Conditional and unconditional branches should be 
avoided as far as they obscure the relationship 
between problem structure and programme structure, 
as much sequential code as possible should be used 


2 






X 






H 


Good against — Difficulties with 
control flow analysis 
Good for — Readability 



hi 



oo 



Item 



ab 



ad 



4 



ag 



ah 



Recommendation 



Backward going branches should be avoided, loop 
statements should be used instead (only for higher 
level languages) 

Branches into loops, modules or subroutines must be 
barred 

Branches out of loops should be avoided, if they do 
not lead exactly to the end of the loop. Exception: 
failure exist 

In modules with complex structure, macros, 
procedures or subroutines should be used so that 
structure stands out clearly 

As a special measure to support programme proving 
and verification computed GOTO or SWITCH 
statements as well as label variables should be 
avoided 

Where a list of alternative branches or case controlled 
statements are used, the list of branch or case 
conditions must be an exhaustive list of possibilities. 
The concept of a 'default branch' should be reserved 
for failure handling 

Loops should only be used with constant maximum 
loop variable ranges 



Priority or 
Importance 



B-5.2 Subroutines and Procedures 



Realization by or in, or with the Help of 



Operating 
System 



Special 
Programme 



User 
Programme 



Programme 
Document 



Hardware 



Check 



D 
C 



Good Against/ Good for 



Good against — Difficulties with 
control flow analysis 
Good for — Readability 

Good against — Difficulties with 

control flow analysis 

Good for — Readability 

Good against — Difficulties with 

control flow analysis 

Good for — Readability 

Good against — Difficulties with 
control flow analysis 
Good for — Readability 

Good for — Ease of understanding, 
because of near neighbourhood 
between condition and its code 



Good for — Clarifying exclusive or 



Good against — Run time problems, 

violating array boundaries 

Good for — Surveyable path number 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


b 


Subroutines or procedures should be organized as 
simply as possible 


I 






X 






C 


Good against — Unnecessary 
complexity 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


ba 
bb 
be 
bd 
be 
bf 


They should have only a minimum number of 
parameters 

They should communicate exclusively via their 
parameters to their environment 

All parameters should have the same form (for 
example, no mixing of call by name and value) 

Subroutines should have only one entry point 

Subroutines should return to only one point for each 
subroutine call. Exception: default exit 

The return point should immediately follow the point 
of call 


3 
1 
3 
1 
1 






X 
X 
X 
X 
X 
X 






C 
C 
C 
C 
C 
C 


Good for — Keeping routines and 
interfaces short and simple 

Good for — Understandability of 
data flow, data flow analysis 

Good against — Difficulties with 
parameter significance 

Good for — Understandable control 
flow, control flow analysis 

Good for — Understandable control 
flow, control flow analysis 

Good for — Understandable control 
flow, control flow analysis 



k> B-5.3 Nested Structures 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 

System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


c 


Nested structures shall be handled with care 


2 






X 






C 


Good for — Intelligibility 


ca 

cb 
cc 

cd 


Nested macros should be avoided 

Procedure valued parameters should be avoided 

Joining of different types of programme action by 
means of nested loop statement" or nested 
procedures should be avoided, if they obscure the 
relationship between problem structure and 
programme structure 

Hierarchies of procedures and loops should be used, 
if they clarify the system structure 


2 

2 
2 

2 






X 

X 
X 

X 






C 

C 

D 
C 

D 
C 


Good against — Creating additional 
macro types 

Good for — Accessibility of 

intermediate results 

Good for — Favouring sequential 

structures 

Good for — Indicating different 
levels of abstraction during 
top-down development 






B-S.4 Addressing and Arrays 


















Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


d 


Simple addressing techniques shall be used 


1 






X 






C 


Good for — Ease of data flow 
analysis 


da 

db 
dc 

dd 


Only one addressing technique should be used for 
each data type 

Bulky computations of indexes should be avoided 
Arrays should have a fixed, predefined length 

The number of dimensions in every array reference 
should equal the number of dimensions in its 
corresponding declaration 


3 

i 
1 

i 






X 

X 
X 

X 






C 

c 
c 

c 


Good for — Uniform interface to 
data base 

Goodfor — Understandable data flow 
Good against — Run time 
difficulties, complex control flow 
Good for — Ease of data flow analysis 
Good for — Understanding 
addressing process 



03 



B-5.5 Data Structures 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Goodfor 


Operating 

System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


e 


Data structures and naming conventions shall be used 
uniformly throughout the system 


1 






X 






D 
C 


Good for — Data flow analysis, 
intuitive comprehension of the 
significance of data elements 


ea 
eb 

ec 
ed 


Variables, arrays and memory cells should have a 
single purpose and structure. The use of equivalence 
techniques should be avoided 

Each variable's name should reflect: 

a) type (array, variable, constant); 

b) region of validity (local, global programme, module); 

c) kind (input, output, internal, derived, count, array 
length); 

d) significance. 

System parameters that can change should be 
identified and their values assigned at a well defined 
outstanding code position 

Constants and variables should be located in different 
parts of the memory 


1 
1 

1 

2 






X 
X 

X 
X 






D 
C 

C 

D 
C 

C 


Good against — Errors in data use, 

artificial timing problems 

Good for — Traceability of data flow 

Good for — Intuitive comprehension 
of data element 

Good for — System understanding, 
changes 

Good against — Poisoning of data 
and code 

Good for — Hardware self- 
supervision 



NOTE — Many real time programme systems make use of a universally accessible 'database' or similar resource. When such global data structures are used, they should be accessed via standard resource 
handling procedures or via communication with standard resource manipulating tasks. 



B-5.6 Dynamic Changes 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


f 


Dynamic instruction changes shall be avoided 


« 






X 






C 


Good for — Control flow analysis 



B-5.7 ] 


intermediate Tests 


















Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


8 


Intermediate tests shall be performed during the 
programme development 


1 




X 









D 


Good for — Finding errors as soon 
as possible 


ga 


The approach to testing should follow the approach to 
design (for example, during top down design testing 
should be made by using simulation of not yet existing 
system parts — stubs — ; after completion of system 
development this should be followed by bottom up 
integration testing) 


1 




X 








D 


Good for — Finding errors as soon 
as possible 


8b 


Each module should be tested thoroughly before it is 
integrated into the system and the test results 
documented 


1 




X 




X 


O 


D 


Good against — Difficulties after 

integration 

Good for — Change management 


gc 


A formal description of the test inputs and results (test 
protocol) should be produced 


1 




O 




X 




D 


Good against — Duplication of work 
Good for — Speeding up licensing 


gd 


Coding errors which are detected during programme 
testing should be recorded and analysed 


3 








X 




D 


Good for — Detection of some 
design errors 


ge 


Incomplete testing should be recorded 


3 








X 




D 


Good for — Clarity 


gf 


In order to facilitate the use of intermediate test results 
during final validation the former degree of testing 
achieved should be recorded (for example, all paths 
through the module tested) 


2 




X 








D 


Good against — Duplication of work 



£ 



w 



B-6 LANGAUGE DEPENDENT RECOMMENDATIONS 
B-6.1 Sequences and Arrangements 



«3 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


a 


Detailed rules shall be elaborated for the arrangement 
of various language constructs 


2 












C 


Good for — Getting a uniform and 
intelligible shape of programme listings 


aa 

ab 
ac 
ad 
ae 


The recommendations should include sequence of 
declarations 

Sequence of initialisations 

Sequence of non-executable code/executable code 

Sequence of parameter types 

Sequence of formats 


2 

2 
2 
2 
2 












C 

c 

c 
c 
c 





B-6.2 Comments 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


b 


Relations between comments and executable or 
non-executable code shall be fixed by detailed rules 


3 












C 


Good against — Difficulties with 

both writing and understanding 

comments 

Good for — Getting meaningful 

comments 


ba 
bb 
be 


It should be made clear what has to be commented 
The position of comments should be uniform 
Form and style of comments should be uniform 


3 
3 

3 












C 

c 
c 





B-6.3 Assembler 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 

System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


c 


If an assembler language is used, extended 
programming rules shall be followed 


1 






X 






C 


Good against — Difficulties of 
assembler programming 
Good for — Avoiding tricks 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in 


, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


ca 


Branching instructions using address substitution 
must not be used. Branch table contents should be 
constant 


1 






X 




X 


C 


Good against — Branches whose 
goal cannot be identified from the 
code at the branching point 


cb 


All indirect addressing should follow the same 
scheme 


1 






X 






C 


Good for — Clarity of ultimately 
addressed memory locations 


cc 


Indirect shifting should be avoided 


1 






X 




X 


C 


Good for — Seeing immediately 
how far shift goes 


cd 


Multiple substitutions or multiple indexing within a 
single machine instruction should be avoided 


1 






X 




X 


C 


Good for — Ease of finding 
ultimately addressed locations 


ce 


The same macro should always be called with the 
same number of parameters 


2 






X 






c 


Good for — Understanding the 
macro's function 


cf 


Labels should be referred to by names rather than by 
absolute or relative addresses 


1 






X 






c 


Good for — Associating a meaning 
with the branching goal 


eg 


Subroutine call conventions should be uniform 
throughout the system and specified by further rules 


1 






X 






c 


Good against — Arbitrary parameter 
types and locations 



B-6.4 Coding Rules 



Item 


Recommendation 


Priority or 
Importance 


Realization by or in, or with the Help of 


Good Against/ Good for 


Operating 
System 


Special 
Programme 


User 
Programme 


Programme 
Document 


Hardware 


Check 


d 


Detailed coding rules shall be issued 


3 














Good for — Uniform and 
understandable shape of programme 
listing 


da 

db 
dc 


It should be made clear, where and how code lines are 
to be indented 

Module layout should be fixed uniformly 

Further details should be regulated according to need 


3 

3 
3 












C 

C 
H 


Good for — Identification of blocks 

Good for — Understanding module 
structure 
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ANNEX C 

(Clauses 1.3 and 6.4.1) 
OUTLINE FOR THE SOFTWARE PERFORMANCE SPECIFICATION 



C-l GENERAL INFORMATION 

C-l.l Summary and Reference to Design 
Methodology 

C-1.2 Summary and Reference to Software 
Functional Requirements 

C-l. 3 Reference to Hardware Performance 
Specifications 

C-1.4 Reference to Software Validation Plan 

C-2 SYSTEM DESIGN LEVEL 

C-2.1 System Survey 

C-2.2 System/Sub-System Control Flow 

C-2.3 External Interfaces 

C-2.4 Global Data Definition 

C-2.5 Diagnostics 

C-2.6 Recovery 

C-2.7 Reference to Integrated Testing Plan 

C-3 SUB-SYSTEM DESIGN LEVEL 

C-3.1 Function 

C-3.2 Traceability to Software Functional 
Requirements 

C-3.3 Control Flow, Interface to Other Modules 
and Branch Limitation 

C-3.4 Operating Conditions 

a) Interruptability 

b) Relocatability 



C-3.5 Algorithm 

C-3.6 Data Requirements 

a) Input/Output 

b) Internal 

C-3.7 Performance Requirements 

a) Accuracy, 

b) Timing, 

c) Hardware Imposed Constraints, and 

d) Security and Access Controls. 

C-3.8 Encoded Error Detection 

C-3.9 Initialization 

C-3.10 Reference to Module or Sub-System Test 
Plan 

C-3.11 Requirements for Interface with Operator 
Console 

C-4 DATA BASE SPECIFICATION 

C-4.1 Description 

C-4.1.1 Identification 

C-4.1.2 Conventions 

C-4. 1.3 Survey of Organization 

C-4.2 Logical Characteristics 

C-4.2.1 Identification 

C-4.2.2 Definition 

C-4.2 3 Relationship to Other Sets 

C-4.2.4 Access Control and Security 
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ANNEX D 

(Clauses 1.3 and 6.2) 
LANGUAGE, TRANSLATOR, LINKAGE EDITOR, ETC 



D-0 For a safety related application of a language, its 
translator and linkage editor, the following more 
detailed recommendations are given in addition to 
those from the main part of this standard. These 
recommendations also apply to any other auxiliary 
system programme. Recommendations for translators 
apply likewise to interpreters, cross compilers and 

D-l GENERAL 



emulators. Similarly the aspects that apply to 
translators and linkage editors should be recognized 
during the selection and formal specification of design 
tools and their use. A project should select 
recommended criteria according to the priority 
indicated. 



Item 


Recommendations 


Priority 


a 


Translator, linkage editor and loader should be thoroughly tested prior to use; operation is considered very 
important 


1 


b 


Reliability data of sufficient quality about translator, linkage editor and loader should be available 


2 


c 


In cases where auxiliary system programmes are used, such as, aids, documentation systems and the like, they 
should be appropriately tested before being employed 


1 


d 


Language syntax should be completely and unambiguously defined 


2 


e 


Semantics should be well and completely specified and understandable 


1 


f 


High level languages should be used rather than machine-oriented ones 


2 


g 


Both the spread of a language and its problem adequacy are considered important 


2 


h 


The recommendations of Annex B should be supported in general and as far as possible 


1 


i 


Readability of produced code is more important than writeability during programming 


2 


k 


Syntactic notations should be uniform; for the same concept not more than one notation should be allowed 


2 


I 


The language should avoid error prone features 


2 


m 


Produced programmes should be easy to maintain 


2 


n 


Input parameters, output parameters and transient parameters should be syntactically distinct 


2 





An optional output that is reviewable should be provided at all stages of the translation process 


3 



D-2 ERROR HANDLING 




Item 


Recommendations 


Priority 


a 


Language translator and linkage editor should provide for detection of as many programming errors as possible 
during translation time or on-line execution 


2 


b 


During on-line execution, exception handling should be possible 


2 


c 


The language may provide assertions 


3 


d 


Errors likely to cause an exception during execution time should include: 






a) exceeding of array boundaries; 

b) exceeding of value ranges; 

c) access to variables that are not initialised; 

d) failing to satisfy assertions; 

e) truncation of significant digits of numerical values; and 
passing of parameters of wrong type. 


1 
1 

3 
2 
2 
1 
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Item 


Recommendations 


Priority 


e 
f 
8 


If any error is detected during translation or linkage time, it should be reported without any attempt at correction 
If it is not clear whether any rules have been violated, a warning should be issued 
During translation time, parameter types should be checked 


2 
3 
3 



D-3 DATA AND VARIABLE HANDLING 



Item 


Recommendations 


Priority 


a 
b 
c 
d 

e 

f 
8 
h 
i 


The range of each variable should be determinable at translation time 

The precision of each floating point variable and expression should be determinable at translation time 

No implicit conversion between types should take place 

The type of each variable, array, record component, expression, function and parameter should be determinable 
at translation time 

Variables, arrays, parameters, etc, should be explicitly declared, including their types 

Variable types should distinguish between input, output, transient procedure and subroutine parameters 

Variable names of arbitrary length should be allowed 

As far as possible, type checking should take place during translation time rather than execution time 

At translation time, it should be checked whether an assignment is allowed to any particular data item 


1 

2 
2 
2 

1 
2 

3 

2 



D-4 ON-LINE ASPECTS 



Item 


Recommendations 


Priority 


a 

b 

c 


During expression evaluation, external assignment should not be allowed to any variable that is accessible in 
the scope of the expression 

Used computing time should be examinable on-line 

On-line error capture should be provided (see D-2). 


1 

3 
1 
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ANNEX E 

(Clauses 1.3 and 7.2. 1.2) 
SOFTWARE TESTING 



E-l SOFTWARE TESTING ACTIVITIES 

This clause is intended to provide guidance for 
software testing. Depending on the programme to be 
tested, the individual kinds of tests are more or less 
effective in finding programme errors. A set of 
complementary testing approaches may be used, 
including a combination of statistical and systematic 
testing. Statistically selected data could be applied to 
search for forgotten cases. 

Supplementary (manual) techniques, however, will be 
code inspection (desk checking) and use of 
mathematical proofs. For each application the 
verification plan may include these different 
techniques and put them into a suitable order. 

A review of possible methods is given in E-4.1. When 
necessary, different approaches and different criteria 
for test data selection within one approach should be 
chosen for different programme parts in order to 
determine whether a particular part is free from errors 
or determine the probability that it fails is below a 
certain acceptance level. The selection depends on the 
internal structure of a programme part, the level of 
reliability required, the demands imposed on it during 
plant operation and the available testing tools. 

Software testing should give consideration to different 
levels of software design (for example, module, 
sub-system and system levels). 

E-2 SYSTEMATIC APPROACHES 

Each module should be tested in a systematic way 
according to well-defined test criteria which specify 
what is to be tested (for example, all statements, all 
arcs, all paths). Automatic testing tools should be used 
as much as possible in deriving test cases. Test results 
are checked with expected results derived from the 
programme module specifications. Parameters should 
be input to and output from the module in the same 
manner as in the safety system. 

According to E-4.2 the classes of possibly remaining 
errors can be determined and as a consequence it will 
be possible eventually to proceed with the testing 
using a different approach. E-4.2 is a check-list, which 
can be interpreted according to the needs of each 
special case. Due to the enormous variety of possible 
practical cases it is not possible to recommend any 
combination of the tests indicated for a particular class 
of applications. It is, however, indicated which tests 
should be performed under all circumstances. On the 
other hand, it is evident that neither all combinations 



of all tests nor all individual tests can be executed in a 
particular application. 

At the sub-system level, the software is partially 
integrated into the system. The sub-system level tests 
assure the proper integration of the software modules. 
A distinction must be made between the case in which 
data flow dependency exists among the software 
modules and the case in which it does not. Testing 
shall be done to provide assurance that all independent 
arcs in the sub-system are correctly followed. Test 
cases at the borders of input domains and at the limits 
of module operational region should be used. 

The same test data set utilized at module level should 
be used. Results should be checked with 
pre-calculated values. Parameters should be input_and 
output from the sub-system in the same manner as in 
the safety system. Where practical, the sub-system 
level testing should involve the actual hardware. 

At the system level, the software is completely 
integrated in the hardware. The system test assures 
proper integration of sub-systems. Testing should be 
performed by running programmes together with a 
realistic simulator, or with a realistic version of the 
system to be monitored or controlled by the safety 
systems. 

This test of the complete system shall be performed in 
accordance with the performance statements given in 
the functional requirements specification. Beyond the 
testing activities described above a systematic timing 
check should be performed. 

E-3 STATISTICAL APPROACHES 

a) Statistical approaches should be utilized to 
complement systematic approaches. The 
general assumptions behind statistical 
approaches are: 

1) Sequence and number of test runs does 
not influence the result of a single test 
run; 

2) Test run is supervised so perfectly that 
each faulty run or failure is detected as 
such; 

3) Number of test runs is large, for ex- 
ample, more than 1 000; and 

4) Nearly no errors or failures are detected. 

b) Statistical approaches are performed for: 

1) testing loop bodies, given that the loop 
structure has been systematically 
analyzed; 
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2) the verification of standard functions 
provided by individuals or organizations 
other than the software developer, if suf- 
ficient operational data are available; 

3) the verification of operating systems 
which are inherently difficult to analyze 
due to their interactive nature and op- 
timised design, if sufficient operational 
data are available; 

4) the verification of the interface between 
standard programming and newly 
developed software, if it is not possible 



to systematically analyze this interface 
exhaustively. 
In E-4.3, the prerequisites marked: 

Al means it is assumed that no errors or failures are 
detected during 'n' test runs; and 

A2 means it is assumed that knowledge about 
programme internals is needed from results of 
programme analysis. 

Dependent on the results of the systematic tests the 
statistic tests should be selected carefully. Normally 
an appropriate mixture will be best for each specific 
case. 
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E-4 TESTING METHODS 

E-4.1 Overview of Verification Method 






No. 


Method 


Aim 


Major Advantages 


Problems During 

Application, Major 

Disadvantages 


Cost and Effort 

Compared with 

Development Cost 


Result 


Relationship to Other 
Methods 


Assessment 


1 


Supervision of testing 
procedure 


To derive a reliability 
figure without 
additional effort 


a) Small additional 
effort for application 

b) No detailed 
knowledge from test 
object required 


a) Reliability figures 
to be gained not 
sufficient 

b) Practical cases 
behave only roughly 
according to theory 


Small 


Probabilistic figure, 
for example, MTBF 


Uses probability 
theory as No. 2 


Difficult to use for 
safety applications 


2 
2.1 

2.2 


Statistical testing 


To derive a reliability 
figure without 
looking into the 
code's details 


No detailed know- 
ledge from test object 
required 




a) Number of 
required test cases 
very high, if 
meaningful results 
are to be obtained 

b) Cost for test can 
be much higher 




Same kind of 
reasoning as No. 1 


Can be reasonably 
applied in a short 
form complementary 
to programme analysis 


According to demand 


To provide a test 
profile that represents 
input states with the 
same probability as 
the online operation 


Probabilistic figure, 
for example, availa- 
bility per demand or 
risk per programme 
life time 


According to 
correctness 


To provide a test 
profile that hits any 
programme property 
with equal probability 


Probabilistic figure, 
for example, limit for 
still contained errors 


3 


Programme proving 


Provide a basis for 
comparison with 
specifications 


Rigorous statement 
on correctness achi- 
evable 


No formalism 
available for finding 
loop assertions or 
loop invariants; error 
prone 


In the same order of 
magnitude or higher 


Correct/not correct, 
as far as proof is 
correct 


Some aspects to be 
used with analysis 


Possibly the only 
reasonable way for 
general 'WHILE' 
loops 



M 

w 



8 



No. 


Method 


Aim 


Major Advantages 


Problems During 

Application, Major 

Disadvantages 


Cost and Effort 

Compared with 

Development Cost 


Result 


Relationship to Other 
Methods 


Assessment 


4 

4.1 
4.2 


Programme analysis 




Brings good results 
with simple 
programmes 


Some programme 
constructs are 
difficult to analyze 




Free from some 
specific error types as 
far as analysis was 
deep enough 


Same kind of thinking 
from programme 
proving is used 




Manual analysis 


To provide a basis for 
a meaningful test or 
for a comparison with 
specifications 


Can be performed 
without additional 
tools 


Error prone 


Slightly less than 
development cost 


Should be used if no 
automatic tool 
available 


a) Should be used as 
widely as possible 

b) Most promising 
approach 


Automated analysis 


As above some-times 
restricted to some 
vaguer quality 
measurement 


a) Only limited hand 
work 

b) Results quickly 
obtained 


a) Many tools require 
additional hand work 

b) Some results of 
such tools are 
difficult to interpret 


Depending on the 
available tool, much 
lower than 
development cost 
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E-4.2 Systematic Tests 
E-4.2.1 General 



No. 


Kind of Test 


Kind of Detected Errors 


To be Performed 


Remarks 


1 


Cases representative for 
programme behaviour in 
general, its arithmetic, timing 


All, but with no guarantee for 
being exhaustive 


Always 


It is assumed that the system 
works correctly, if the cases are 
executed correctly 


2 


All individually and explicitly 
specified requirements 


Forgotten functions detected 
completely 


Always primarily, if required 
functions are specified in detail 


a) Can be an exhaustive test, il 
functions are kept completely 
separate 

b) Does not say much on 
timing problems 


3 


All input variables in extreme 
positions (crash test) 


Timing errors, but with no 
guarantee. Overflow, 
underflow 


Always 




4 


Operation of all external 
devices 


Hardware and software 
interface design errors 


Always 




5 


Static cases and dynamic paths 
which are representative for the 
behaviour of the technical 
process 


All, but with no guarantee 


Always 


Especially valuable, if 
simulator of technical process 
is available 


6 


All cases and paths that the 
technical process can show 
with respect to the software 


All, as far as ever relevant 


If technical process behaviour 
is well known and not too 
manifold 


Only feasible, if process 
behaviour is simple, caution 
with changes 



E-4.2.2 Path Testing 



No. 


Kind of Test 


Kind of Detected Errors 


To be Performed 


Remarks 


1 


Every statement executed at 
least once 


Inaccessible code 


Always 




2 


Every outcome of every branch 
executed at least once 


Errors in control flow, with no 
guarantee of completeness 


Always 


Contains 5; can be exhaustive, 
if no loops no timing problem 

Purely combinatorial problem 
mapped on programme 
structure 


2a 


Every predicate Verm exercised 
to each branch 


Errors in control flow and data 
flow 


If combination of tests 8 and 12 
is not applied 


Contains 8; included in 
combination of 8 and 12 


2b 


Each loop executed with 
minimum, maximum and at 
least one intermediate number 
of repetitions 


Errors in loop control and array 
data handling 


Always, if programme contains 
loops 




3 


Every path executed at least 
once 


All the erroneous control flow 


If combinatorial problem ■ 


Only feasible for modules 

Contains 8: remember that each 
new loop repetition leads to a 
new path 



E-4.2.3 Data Movement Testing 



No. 


Kind of Test 


Kind of Detected Errors 


To be Performed 


Remarks 


1 


Every assignment to each 
memory place executed at least 
once 


Errors in data flow, but with no 
guarantee 


Arrays used 




2 


Every reference to each 
memory place executed at least 
once 


Errors in data flow, exhaustive 
in special cases 


Arrays used 


Contains 10 in most cases 

Only reasonable in connection 
with 10 


3 


All mappings from input to 
output executed at least once 
each 


All data flow errors 


Always for individual segments 


Only feasible for modules 
Possibly covered by 8, 9 or 7 
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E-4.2.4 Timing Testing 



No. 


Kind of Test 


Kind of Detected Errors 


To be Performed 


Remarks 


1 


Checking of all time constraints 


Timing errors, computing time 
too long 


Always 




2 


Maximum possible 
combinations of interrupt 
sequences 


Organizational errors 


If number not too large 




2a 


All significant combinations of 
interrupt sequences 


Organizational errors 


Always 





E-4.2.5 Miscellaneous 



No. 


Kind of Test 


Kind of Detected Errors 


To be Performed 


Remarks 


1 


Check for correct position for 
all boundaries of the input data 
space 


Erroneous sub-division of input 
data space 


If analogue input is used 


Number and kind of input data 
sub-areas to be found by 
analysis 


2 


Check for sufficient accuracy 
of arithmetical calculations at 
all critical points 


Numerical errors, errors in 
algorithms, rounding errors 


If word length of computer is 
short; complicated arithmetic 
used 




3 


Only for programmes: test of 
module interfaces and module 
interaction 


Incorrect data transfer between 
modules 


Always 


Test aid welcome 


3a 


Every module invoked at least 
once 


Incorrect control flow and 
incorrect data flow between 
modules, with no guarantee 


Always 




3b 


Every invocation to a module 
exercised at least once 


Always 





£-4.3 Statistical Tests 



No. 


Kind of Test 


Kind of Detected Errors 


To be Performed 


Remarks 


1 


Each input data combination 
with same probability as during 
on-line application, n test runs 


Failure probability per demand 

p < (2.99/n) with 

p = 95% 

p< (4.6/«)with 

p = 99% 




Detailed knowledge of 
operation conditions 


2 


Each input data combination 
with equal probability, n runs 


Failure probability per arbitrary 
run, formulae as in row 1 given 
above 




" 


3 


Each programme property 
tested with equal probability, n 
properties tested 


Probability of error of an 
arbitrary and distinct 
programme property, formulae 
as in row 1 given above 


Only reasonable for 
programme parts not 
analysable 


Knowledge on detailed 
programme structure in order 
to ensure equal probability 


4 


n runs such that any potential 
error is detected with equal 
probability p s during one run 


Probability to detect an 
arbitrary and distinct potential 
error 

p=l-(l-p s ) n 


Difficulty to estimate p s 


Probability />s to touch an error 
known in order to ensure equal 
probability 


5 


As 3, N programme properties, 
n test runs, nN random selection 
of properties with return 


Probability to test each 
programme property at least 
once 

n-l 

p= 1+2 (-iy(N/f)l(N-l)/N] tt 


In order to ensure equal 
probability 


6 


n test points randomly 
distributed in Jfc - dimensional 
programme input domain 


Mean distance of two test 
points in direction of an 
arbitrary axis 


Useful to test correctness of 
positions of boundaries of 
sub-domains 
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ANNEX F 

(Clauses 1.3, 4.1.8, 6.4.1 and 8.1.1) 
LIST OF DOCUMENTS NEEDED 

F-l DOCUMENTS RELATING TO SOFTWARE PRODUCTION 



Milestones 


Name of Document 


Clause 


Ml 


Safety systems requirements for digital systems 


4 


M2 


Software requirements specification (functional and reliability requirements) 

Quality assurance plan 

Detailed recommendations (programme development) 

Software verification plan 

System integration plan 


4 

3.2 
5.3 
6.2.1 
7.1,7.2 


M3 


Software performance specification 
Design verification report 
Software test specification 
Specification of periodic test procedures 


5,5.4.1 
6.2.2 
6.2.3.1 
4.8, 10.3 


M4 


Software test report 

Periodic tests, test coverage assessment 


6.2.3.2 
10.3.2 


M5 


Integrated system verification, test report 
Computer system validation plan 
Training programme 


7:7 

8 

10.2.1 


M6 


Computer system validation report 
Training plan 
User manual 
Commissioning test plan 


8.1 

10.2.2 
10.2.2 
10.1.1 


M7 


Commissioning test report 


10.1.1 



F-2 DOCUMENTS RELATING TO SOFTWARE MODD7ICATIONS 



Name of Document 


Clause 


Anomaly report 


9.3.1 




(MA) 


Software modification request 


9.1 




(PR) 




9.3.1 




(MA) 


Software modification report 


9.2 




(PR) 




9.3.1 




(MA) 


Software modification report, 'field document' 


9.3.4 




(MA) 


Software modification control history 


9.2 




9.3.4 


(PR) : Document issued during production phase. 


(MA) : Document issued during maintenance phase. 
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F-3 DOCUMENTATION ORGANIZATION RELATING TO THE SOFTWARE REALIZATION 
F-3.1 Software Generation 



* 



System 
Requirements 



Milestones" 



M 



Software 
Requirements 



Software 
Design 



M2 



M3 



Software life cycle 



00 

i 



Coding 



M4 



Quality 
assurance plan 



Safety systems 
requirements 



Detailed 

recommendations 

(Program 

development) 



Hardware/Software 
Integration 



Computer System 
Validation 



Commissioning 



MS 



M6 



Exploit/ 
Maintenance 



Delivery 



Software 
requirement 



Software 
performance 
specification 




Software 

verification 

plan 




Design 
verification report 



Software test 
specification 



t 



Software 
test report 
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procedures 
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coverage 
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F-3.2 System Integration 
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Requirements 
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Design 



Coding 



Software life cycle 
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Integration 



Milestones *" Ml" 
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Validation 
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program 
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Delivery 
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F-33 Modification 
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ANNEX G 

(Foreword) 
COMMITTEE COMPOSITION 

Nuclear Instrumentation Sectional Committee, LTD 26 



Organization 
Indira Gandhi Centre for Atomic Research, Kalpakkam 

Atomic EncTgy Regulatory Board, Mumbai 

Atomic Minerals Division, Hyderabad 
Bhabha Atomic Research Centre, Mumbai 



Centre for Advanced Technology, Indore 

Electronics Corporation of India Limited, Hyderabad 
Indian Institute of Technology, Kanpur 

Indian Plasma Research Institute, Gandhinagar 
Ministry of Defence (DRDO), New Delhi 
Nuclear Power Corporation, Mumbai 

Nuclear Science Centre, New Delhi 
PLA Electro Appliances Ltd, Mumbai 

Saha Institute of Nuclear Physics, Kolkata 

Variable Energy Cyclotron Centre, Kolkata 
BIS Directorate General 



Representative(s) 
Shri P. Swaminathan [Chairman) 

Shri S. A. V. Sathyamurthy (Alternate) 
Shri P. R. Krishnamurthy 

Shri P. Hajra (Alternate) 
Shri R. Sreehari 
Dr S. K. Kataria 

Shri Debashis Das (Alternate I) 

Shri P. K. Mukhopadhyay (Alternate II) 
Shri B. J. Vaidya 

Shri A, G. Bhujale (Alternate) 
Dr M. S. R. Murty 
ProfS. Qureshi 

Prof P. Munshi (Alternate) 
Dr AnuragShyam 
Shri G. C. Bhola 
Shri S. Ramakrishnan 

Shri R. Y. Apte (Alternate) 
Dr R. K. Bhowmik 
Shri N. R. Shah 

Shri K. K. M. Nair (Alternate) 
DrSuvenduBose 

Dr Pratap Bhattacharya (Alternate) 
Shri N. K. Mukhopadhyay 
Shri Vuai, Director & Head (LTD) 
[Representing Director General (Ex-officio)} 



Member Secretary 

Shri Praveen Kumar 

Deputy Director (LTD), BIS 
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